In the short and medium term, I think we should keep the mw-ui-button class working, but aim to shrink the code that is required to support it. We should do this regardless of whether we want to support this feature in perpetuity, or if we want to deprecate it and eventually remove it. If we do the latter, we will also first need to provide an alternative that these uses can be migrated to.

I propose approaching this as follows:

• Remove uses of mediawiki.ui in software first (as opposed to in content). This is captured by the other subtasks of T182050.
• Once the last use of each component has been removed, delete that component. Eventually, only the button component will be left in mediawiki.ui, everything else will have been deleted.
• Remove extraneous code from the mw-ui-button styles that is not needed to support the in-content use cases (for example, styles for buttons that are adjacent to checkboxes). This should reduce the size of the mediawiki.ui.button RL module to something pretty small.
• Decide whether to provide a Codex-based alternative, and what that would look like
  • For example, this could be a CSS class that functions the same way as mw-ui-button, but is called something else (e.g. cdx-button)
  • Or it could be a parser tag, like how the InputBox extension provides a tag that can be used to render a text input plus a button
• If and when a Codex-based alternative is built, then we can decide whether to keep supporting mw-ui-button in perpetuity, or whether to phase it out in favor of the new alternative

It is the only major mediawiki.ui component used in on-wiki content

Is it really the only major MediaWiki UI component that’s used in on-wiki content, or the only one that’s in widespread use? Did you check?

an alternative plan will be needed for on-wiki content that does not rely on Codex.

You mean that a plan that does not rely directly on Codex CSS, don’t you? A stable interface that uses Codex under the hood should be okay, shouldn’t it.

In T355242#9467706, @Catrope wrote:

• Remove uses of mediawiki.ui in software first (as opposed to in content). This is captured by the other subtasks of T182050.
• Once the last use of each component has been removed, delete that component. Eventually, only the button component will be left in mediawiki.ui, everything else will have been deleted.
• Remove extraneous code from the mw-ui-button styles that is not needed to support the in-content use cases (for example, styles for buttons that are adjacent to checkboxes). This should reduce the size of the mediawiki.ui.button RL module to something pretty small.

Couldn’t a new ResourceLoader module be created now, and that be loaded when mw-ui-button is used in content (provided that really nothing else is used in content)? That would mean that deprecation warnings about the mediawiki.ui.button module could be taken seriously. While the new module could cause a slight increase of resources downloaded if both mediawiki.ui.button and the new module are loaded (the former by an extension or a gadget/user script), it would cause a decrease of resources downloaded on pages that use MediaWiki UI only in content, and would speed up the deprecation process by highlighting actionable cases (i.e. when an extension/gadget/user script uses MediaWiki UI).

In T355242#9470307, @Tacsipacsi wrote:

It is the only major mediawiki.ui component used in on-wiki content

Is it really the only major MediaWiki UI component that’s used in on-wiki content, or the only one that’s in widespread use? Did you check?

It's the only one that is supported, in the sense that we currently have code that checks if the content contains mw-ui-button, and if it does loads the mediawiki.ui.button module. No other CSS class gets that treatment. You also can't use most of the other MediaWiki UI components in wikitext because you're not allowed to generate the right HTML tags to use them. mw-ui-button applies to <a> tags (links), which wikitext allows, but mw-ui-checkbox, mw-ui-radio and mw-ui-input apply to various types of <input> tags, which you can't generate with wikitext (at least not directly -- you can generate them using the InputBox extension, but that doesn't let you set CSS classes). The only other component that you could conceptually use is mw-ui-icon (it applies to <span> tags, which wikitext allows). The number of uses of mw-ui-icon in content is very low. A global search for mw-ui-icon that excludes pages with a . in them (in an attempt to exclude JS/CSS pages; it wouldn't let me do that properly) shows 112 results, most of which are text talking about mw-ui-icon rather than content using it. Of the ones that are content using it, most already didn't work.

an alternative plan will be needed for on-wiki content that does not rely on Codex.

You mean that a plan that does not rely directly on Codex CSS, don’t you? A stable interface that uses Codex under the hood should be okay, shouldn’t it.

Yes, and that's what I propose. If we want to provide an alternative, it should probably be Codex-based under the hood.

Couldn’t a new ResourceLoader module be created now, and that be loaded when mw-ui-button is used in content (provided that really nothing else is used in content)? That would mean that deprecation warnings about the mediawiki.ui.button module could be taken seriously. While the new module could cause a slight increase of resources downloaded if both mediawiki.ui.button and the new module are loaded (the former by an extension or a gadget/user script), it would cause a decrease of resources downloaded on pages that use MediaWiki UI only in content, and would speed up the deprecation process by highlighting actionable cases (i.e. when an extension/gadget/user script uses MediaWiki UI).

We could do that, but I'm concerned that loading both the stripped mw-ui-button styles and the full ones could cause bugs. What I think could work is if we split the mw-ui-button styles into a piece that is needed for content and a piece that isn't, and put those in different modules, with the non-content module depending on the content module. Then we could un-deprecate the content module, and get the benefits you want (less code loaded, no undue deprecation warnings) while avoiding potential bugs (because the same styles are loaded, without double-loading or them overriding each other). However, we should weigh the complexity and effort of doing that against how quickly we think we can get rid of the software uses of mw-ui-button.

FWIW I think these are the viable options that we've discussed so far:

• One option is to do nothing and let these degrade to links. While others do, personally, I don't see this as a breaking change (in fact in many situations it is an improvement).

• A second option is to encourage the use of a template. The https://www.mediawiki.org/wiki/Template:Clickable_button_2 template is one option and probably the path of least resistance. It has taken a frozen snapshot of the existing MediaWiki UI button styles. It is much more optimized than the MediaWiki core library. The downside is it won't stay in sync with Codex but that seems equivalent to option 4.

• A third option is to promote usage of Extension:InputBox - that seems to encourage proper use of buttons (in a form) rather than links disguised as buttons. It currently uses MediaWiki UI but needs to be ported to Codex (and it should be straight forward to do that and it's on the roadmap already). This may limit the usage of these buttons to things that are actually buttons (E.g. not links) but we could create new components for those use cases (for example I don't think Vote should ever be a button - we could provide better treatments for those).

• A forth option is to maintain MediaWiki UI indefinitely (which will likely mean it persists for a long time with all the problems (security, CSS bloat that we've discussed previously similar to the problems we've seen with jquery.ui being loaded on page load). As you say a lot of those styles will be redundant, and this can be made smaller, but presumably it will need to make use of design tokens to stay relevant and won't benefit from upstream changes in Codex. The only benefit over option 2 is color changes would be propagated to the module.

Note: as discussed please remember "popularity" of MediaWiki UI in templates is overinflated due to a large amount of mass messages that appear in talk namespaces (without using a template) and translations of pages in MediaWiki/metawiki. I'd recommend using the query https://global-search.toolforge.org/?q=mw-ui-button&regex=1&namespaces=0%2C2%2C4%2C6%2C8%2C10%2C12%2C14&title=%5B%5E%5C%2F%5D* when thinking about how these styles are used and what to do here.

There's clearly something I don't understand. You build a whole palette and graphic guidelines, update skins, standardize nomenclatures between Codex mediawiki.skin.defaults.less; /mediawiki.skin.variables.less... Years of work. But it's impossible for communities to easily reuse classes when Codex has adopted a rather atomic approach to CSS rules? Neither we could hope to use generated Codex CSS components classes?

Did it ever occur to you that, even though they're volunteers, slower and grumpier, the volunteer developers who maintain the wiki templates might want to unify the appearance of community productions with your work... precisely to respect your work and maintain global harmony? I don't think it's such a stupid idea, given how heterogeneous community production complicates the development of a night mode alone.

I'm not even sure that anyone at WMF is aware that, for example, frwiki has already updated in 2018 dozens of wikis portals/projects with similar appearances from the soon-to-be-archived Wikimedia Design Style Guide. https://fr.wikipedia.org/wiki/Projet:Charte_graphique
Even @Jdlrobson already noted than copying/pasting directly the source code is not a long-term solution, since the project will be again in debt, not synced with the upstream.

On the other hand, I recognize that for developers who maintain gadgets, even if over the years there have been quite a few deprecations, from jQuery, to OOUI, and now the move to Codex, well they can do pretty much what they want.

This isn't mean criticism, but rather a reminder as a MediaWiki user with a technical profile, letting you know that if a few of us who hang around here and bridge the gap between your techy productions and their effects on the community end up not really understanding the direction you're taking, it could get complicated... Or else display in big red letters that Codex classes will never be available other than through their use directly in the MediaWiki source code. And that, in any case, this was not an objective.

You can't get upset when you realize that every community uses a button style you've developed... If there's a use for it, there's a need for it. If all use it, it's precisely to have a button looking like the other buttons you've implemented in the UI. With the opening of Wikifunctions, I thought we'd pretty much understood the problem.

Like, even @import 'mediawiki.skin.defaults.less' with TemplateStyles will be a no?

Edit: I hit the templatestyles-error-unrecognized-rule message, and it seems it always was a no: T56864.

Edit-Edit: you are going to make someone create a gadget loading everything on every page to force generate classes, with a trip to the asylum. 😁

Edit-Edit-Edit: so much complicated, but I think I got a partial solution: T340477

In T355242#9483727, @Lofhi wrote:

There's clearly something I don't understand. You build a whole palette and graphic guidelines, update skins, standardize nomenclatures between Codex mediawiki.skin.defaults.less; /mediawiki.skin.variables.less... Years of work. But it's impossible for communities to easily reuse classes when Codex has adopted a rather atomic approach to CSS rules? Neither we could hope to use generated Codex CSS components classes?

Did it ever occur to you that, even though they're volunteers, slower and grumpier, the volunteer developers who maintain the wiki templates might want to unify the appearance of community productions with your work... precisely to respect your work and maintain global harmony? I don't think it's such a stupid idea, given how heterogeneous community production complicates the development of a night mode alone.

To be clear, we are not saying you cannot use Codex styles in wikitext, we're saying we cannot guarantee that the styles are stable at this time. Guaranteeing stability here would mean that any time we want to make a change to Codex's underlying styles, whether for CSS components or JS-based ones, we'd need to factor in the impact to all template maintainers and users of the styles in content. This is not to say it won't happen, but we're not ready to make that commitment now with the rapid rate of Codex development.

I'm not even sure that anyone at WMF is aware that, for example, frwiki has already updated in 2018 dozens of wikis portals/projects with similar appearances from the soon-to-be-archived Wikimedia Design Style Guide. https://fr.wikipedia.org/wiki/Projet:Charte_graphique
Even @Jdlrobson already noted than copying/pasting directly the source code is not a long-term solution, since the project will be again in debt, not synced with the upstream.

The Wikimedia Design Style Guide is being archived, but only because it is now folded into Codex, not because we are trying to overhaul the guidelines themselves. Stylistically things have not changed too much. I agree that copy/pasting is not ideal.

On the other hand, I recognize that for developers who maintain gadgets, even if over the years there have been quite a few deprecations, from jQuery, to OOUI, and now the move to Codex, well they can do pretty much what they want.

Maybe I'm misunderstanding, but gadget developers are expected to transition as well. See T346468. The difference with gadgets is that we have a better way of delivering and managing changes to the library. That's also part of T313945 more broadly.

This isn't mean criticism, but rather a reminder as a MediaWiki user with a technical profile, letting you know that if a few of us who hang around here and bridge the gap between your techy productions and their effects on the community end up not really understanding the direction you're taking, it could get complicated... Or else display in big red letters that Codex classes will never be available other than through their use directly in the MediaWiki source code. And that, in any case, this was not an objective.

You can't get upset when you realize that every community uses a button style you've developed... If there's a use for it, there's a need for it. If all use it, it's precisely to have a button looking like the other buttons you've implemented in the UI. With the opening of Wikifunctions, I thought we'd pretty much understood the problem.

We appreciate the feedback, and this task exists precisely to acknowledge the validity of the use case and welcomes suggestions on how we can preserve it without maintaining mediawiki.ui indefinitely.

Like, even @import 'mediawiki.skin.defaults.less' with TemplateStyles will be a no?

Please see the discussion in T355244.

In T355242#9483727, @Lofhi wrote:

There's clearly something I don't understand. You build a whole palette and graphic guidelines, update skins, standardize nomenclatures between Codex mediawiki.skin.defaults.less; /mediawiki.skin.variables.less... Years of work. But it's impossible for communities to easily reuse classes when Codex has adopted a rather atomic approach to CSS rules? Neither we could hope to use generated Codex CSS components classes?

Did it ever occur to you that, even though they're volunteers, slower and grumpier, the volunteer developers who maintain the wiki templates might want to unify the appearance of community productions with your work... precisely to respect your work and maintain global harmony? I don't think it's such a stupid idea, given how heterogeneous community production complicates the development of a night mode alone.

Yes this did occur to us, but unfortunately there are some technical barriers that need to be solved before Codex design tokens or Codex CSS-only components can be made available for use in wiki content. We aim to eventually address those, because we would love it if the content would follow the same design system as the interface. It also has the potential to make it easier for content to adapt to dark mode (with the caveat that the implementation strategy for dark mode isn't totally settled yet).

As Chris said, T313945 tracks the overall effort to support Codex use in Gadgets (including design tokens, CSS-only components, and Vue components), and T355244 tracks the ability to Codex design tokens in TemplateStyles. The other aspect of what you talked about is using Codex CSS-only components in content directly (through wikitext / templates / Lua, as opposed to through TemplateStyles / Gadgets), analogous to mw-ui-button; there isn't a task that covers that precisely just yet, but I intend for one to come out of this task. The "path forward" that the title of this task calls for could involve a holistic solution for using Codex CSS-only components in content (think something like <inputbox>), or just continued support for class="mw-ui-button" but with Codex tokens used behind the scenes, or something in between.

Thanks for the details, I guess we can just wait for things to progress for now.

Maybe a bit out-of-topic, but I don't want to scatter the discussions: are you going to do something with InputBox? Burying it completely, or modifying it? Because I'm currently activating DiscussionTools by default on all historical community frwiki pages that are similar to discussions with other contributors. Several pages use this extension.

Some pages are directly using the dtpreload=1 URL parameter, but I am planning to switch to InputBox with usedt=1.

In T355242#9486929, @Lofhi wrote:

Thanks for the details, I guess we can just wait for things to progress for now.

Maybe a bit out-of-topic, but I don't want to scatter the discussions: are you going to do something with InputBox? Burying it completely, or modifying it? Because I'm currently activating DiscussionTools by default on all historical community frwiki pages that are similar to discussions with other contributors. Several pages use this extension.

Some pages are directly using the dtpreload=1 URL parameter, but I am planning to switch to InputBox with usedt=1.

I have no intention to bury InputBox, nor do I think anyone else does. Personally, my ambition is to at least convert InputBox to Codex (so that it uses Codex's TextInput and Button components under the hood, as opposed to OOUI widgets; but otherwise keep it as-is), and then consider whether we want to extend InputBox or create something like it for embedding Codex CSS-only buttons or whatever else we decide needs embedding. So I think InputBox is potentially part of the puzzle, but I would advocate for not making breaking changes to it.

Does T356677 made Codex CSS-only components available by default on every request on Vector 2022 (see example)? It seems that skins.vector.search.codex.style is autoloaded. Anyway, if that's the case, it doesn't justify using the Codex components directly on a wiki, right?

In T355242#9687103, @Lofhi wrote:

Does T356677 made Codex CSS-only components available by default on every request on Vector 2022 (see example)? It seems that skins.vector.search.codex.style is autoloaded. Anyway, if that's the case, it doesn't justify using the Codex components directly on a wiki, right?

That changes makes it so that only the components needed for TypeaheadSearch are loaded by default, so I think the answer to your question is no.