Some ideas of how this could be supported:

• Support as @stable only inside a certain page e.g. Template:CdxButton (to minimize amount of changes that are necessary when making breaking changes)
• Provide a parser function for adding Codex button markup
• Require communities to provide and manage their own template styles.

Provide a parser function for adding Codex button markup

T101666: Create parser tag(s) that render OOUI PHP widgets exists since a while for... the same? question.

See also https://gerrit.wikimedia.org/r/c/mediawiki/core/+/955978/comments/3af6727a_8abf4d46.

To support migrations described in T346468 we should make Codex search styles load in the same way that mediawiki ui does - in that if button markup is detected in the article content we load the module in other skins e.g. Monobook,Timeless. Modern, CologneBlue and Vector.

Possible, but makes it hard to find all usages (e.g. what if the class name is concatenated? the auto-loading works, as Skin.php sees the concatenated class name, but global search won’t find it) and being a kind of “magic”, it’s hard to understand for template authors.

• Provide a parser function for adding Codex button markup

This addresses the tracking (the parser function can add a tracking category) and discoverability/understandability issues. However, it has the same problem as TemplateStyles: the template page could look perfect if the TemplateStyles stylesheet is outside of the <onlyinclude> block, but transclusions will break – except if another template does load the required stylesheet, making hard to notice and debug such issues.

T101666: Create parser tag(s) that render OOUI PHP widgets exists since a while for... the same? question.

Not exactly the same question. It probably covers 99% of the uses of mw-ui-* classes in the best possible way (trackable, understandable, no way to mess up by not adding the styles), but it may not cover some creative uses of these classes. I’d say it’s worth a try, only after creating the parser tags can we really see if there are cases it doesn’t cover.

• Support as @stable only inside a certain page e.g. Template:CdxButton (to minimize amount of changes that are necessary when making breaking changes)

This would be hard to enforce, as templates are routinely forked. (It’d also be a question how would the name be determined. Literally Template:CdxButton? Not good for non-English wikis. A Wikidata item? Not good for wikis not connected to Wikidata (beta cluster, Wikitech, third-party wikis).)

• Require communities to provide and manage their own template styles.

I think creating forks is the worst possible solution: it won’t be kept in sync with eventual upstream changes, won’t reflect eventual skin-specific differences (e.g. MediaWiki UI buttons have slightly different border radii on MonoBook) and require more work from template maintainers without giving them more freedom (if they want to match the software-generated buttons, they don’t have the freedom to change the styles).

<span class='cdx-button'>Button text</span>

on a wiki page gives incorrect background color and color of the border. Tested on old vector skin.

Used span, because <button></button> and <input></input> is not allowed on wiki pages (and I am not asking it to be).

In T346469#9171268, @Snaevar wrote:

<span class='cdx-button'>Button text</span>

on a wiki page gives incorrect background color and color of the border. Tested on old vector skin.

Used span, because <button></button> and <input></input> is not allowed on wiki pages (and I am not asking it to be).

Thanks for flagging this. Yes this would be another blocker as Codex does not support buttons as span elements.

Hey @Jdlrobson – in response to the original question on this task: "Is codes-search-styles stable for templates to use?" – my answer would be no. I would discourage template authors from relying on this module right now.

At some point in the very near future I hope that we will be able to settle on a direction for Codex code-splitting in ResourceLoader. Per this comment, part of the idea behind the solution we are proposing is that it would allow developers to request the CSS-only version of an arbitrary collection of Codex components in addition to the JS versions of those components. I think that modules defined in this way would be more suitable for template authors to rely on if they want to embed CSS-only Codex components into templates (which I support).

Once we have the code-splitting problem solved, I actually think we'll remove the codex-search module altogether in favor of allowing a CodexModule to specify that it only needs the TypeaheadSearch component, etc.

On a related note, we're going to move forward with T335324 very shortly meaning that codex-search will no longer be available in NPM. We'll continue to make it available in MW until we have a code-splitting feature in place (but hopefully this happens soon, within a few months).

Also, on the question of how to best generate/work with markup for Codex CSS-only components, we have T326850 as a long-standing task on our backlog that has not yet received much attention. If having some kind of Codex PHP tooling would be useful to WMF developers and to the community, let us know and we can think about how to approach this.

Sorry let me rephrase my question.

"Are Codex CSS components stable for templates to use"

(the codex-search-styles module is just an implementation detail)

In T346469#9180452, @Jdlrobson wrote:

Sorry let me rephrase my question.

"Are Codex CSS components stable for templates to use"

(the codex-search-styles module is just an implementation detail)

We're getting ready to launch the 1.0 version of Codex (which we hope to have out by end of next month). Prior to this release, the answer would still be no.

But after that, it's a question I guess we'll need to answer. In my mind this is where having a programmatic way to generate compatible Codex markup in PHP would be beneficial – it would save us from a situation where we become afraid to make any changes to component markup or styles because a bunch of hard-coded template markup exists on-wiki which we would risk breaking (something I'd really love to avoid).

I can take this question back to the team for further discussion.

Change 963840 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Implement <mw-button> tags in wikitext for Codex button

https://gerrit.wikimedia.org/r/963840

I had a closer look at this today and have come to the conclusion that usage suggests that only a button parser function is needed here. Most buttons do not have icons and the mw-ui-icon markup is seldom used on wikis With that in mind I think https://gerrit.wikimedia.org/r/c/mediawiki/core/+/963840 is the MVP here - a parser function that allows creation of buttons like so:

<mw-button href="/wiki/Foo" weight="primary">Button primary</mw-button>
<mw-button href="/wiki/Foo" weight="primary" action="progressive">Button primary progressive</mw-button>

<mw-button href="https://google.com" action="destructive">Destructive button</mw-button>


<mw-button>Button

with new lines

</mw-button>

• href is quite unconventional. Where external links are allowed (image syntax is what comes to my mind), it’s called link, and is interpreted as a page title (and not as a relative URL) if it’s not an external link. It’s also important to add rel="nofollow" to any external links to make spamming not worth it.
• Why plaintext-only content? Current solutions allow wikitext in content; having to check all usage before replacement would make template maintainers’ lives more complicated, and I see no reason not to allow wikitext. (Cite, for example, allows wikitext in its parser tag, so it’s possible.)

In T346469#9232161, @Tacsipacsi wrote:

href is quite unconventional. (Snip)

Agreed, and I think taking inspiration from the file parameter naming and function is the right approach. The Phonos extension is also looking to add a similar parameter with that name. ( T348093 )

Why plaintext-only content?

The content is being stuffed into an a, which pretty significantly reduces the set of valid internal HTML to div and a handful of inline content. But maybe it's ok to leave that to template authors and others?

my thoughts

This is not a button, it's a link styled like one. Which I think may be appropriate for most users, considering the accessibility angle, but it makes me wonder if calling it an mw-button is appropriate. Semantic mismatch is a thing.

... I am also not entirely certain this task or the other is the best place to be providing feedback on the implementation of the markup. @matmarex's previous patch there looks a bit more complete in a few ways, so maybe some more inspiration to take.

Why plaintext-only content

Codex buttons currently work this way. Having stylistic elements like <b> or <i> inside the button would impact its display. What HTML are templates using? Could you give some examples? To be clear I'm talking about HTML output here. It would be fine to have wikitext that resolves to plain text.

My personally feeling is if I was supporting this API is that this would be a required and reasonable constraint - as otherwise we'll be dealing with all sorts of edge cases.

href is quite unconventional. (Snip)

that's easy enough to fix. The main point of the patch is to decide whether we are willing to support a parser function.

@matmarex's previous patch there looks a bit more complete in a few ways, so maybe some more inspiration to take.

Yes. This patch is a simplified version of that one. I used it as the starting point for this patch. My inspiration/instinct was to restrict it as much as possible at least to begin with as I'm fairly confident it covers most of the use cases I see on wiki :-)

Hey @Jdlrobson – thanks for bringing this patch to my attention.

I think it would be good for my team (Design Systems, the maintainers of Codex) to discuss whether it makes sense to expose some CSS-only components in parser tags in this way before moving forward here. One consideration is that we don't really want to encourage "links that look like buttons" usage (we do support this but we strongly recommend against it in the docs).

I understand that there are a lot of old templates which already do this, and that you want to migrate away from MediaWiki UI in a straightforward way to the Codex equivalent. I just worry about sending a message to the wider community that this styling <a> tags like buttons is fine and can be done anywhere – this is really something that we'd like to discourage.

Also, I assume that the patch in its current state would need to be be updated to include a method to safeguard against XSS attacks before it could move forward, right? I don't know a lot about what is and isn't allowed in on-wiki template code.

In T346469#9240849, @egardner wrote:

(we do support this but we strongly recommend against it in the docs)

Unfortunately you do so ex cathedra, without providing any explanation as to why. In addition to it not being really possible to use <button>s in wikitext (free-standing buttons make sense only if there’s a JavaScript event handler, which is not possible to attach in wikitext), I also don’t see the reason to discourage this use, as there are two orthogonal dimensions:

• Intent: style as button if it’s a call to action, style as link if it’s for navigation
• Implementation: use <button> if it submits a form or has a JavaScript click handler, use <a> if it points to a URL

If a wikitext button for example opens the edit or new topic form, an action special page, a Toolforge tool completing some process etc., it’s a call to action. However, due to the technical limitations of wikitext, there’s no other way than it pointing to a URL.

By the way, pointing to a URL also allows the user to open the form in a new tab, window, private window, copy the URL and open it in a different browser etc. rather than doing what the document author thought they should do, so I actually consider links (whether styled as links or buttons) superior to buttons wherever it’s technically possible to use them.

In T346469#9240654, @Jdlrobson wrote:

Having stylistic elements like <b> or <i> inside the button would impact its display. What HTML are templates using? Could you give some examples? To be clear I'm talking about HTML output here. It would be fine to have wikitext that resolves to plain text.

I don’t have any examples at hand, and I have also no idea how to find some, but as a theoretical example, I actually think <i> would make sense, e.g. the button text “Open the New topic form” uses italic to make it clear where the name of the form starts and stops. If you decide not to add support for wikitext in the button content, at least could you please add a tracking category if you notice wikitext (e.g. htmlspecialchars($content) !== $content) so that we can reconsider this decision based on actual usage, and also template maintainers can fix cases where wikitext was used in the button text inappropriately or without a good reason?

Incidentally, cf. T106948, Extension:InputBox might be a useful reference for what types of things are needed on-wiki; and obsoleting it might not be a bad goal when deciding what facilities Codex should make available for use from wikitext.

In T346469#9242226, @Tacsipacsi wrote:

In T346469#9240849, @egardner wrote:

(we do support this but we strongly recommend against it in the docs)

Unfortunately you do so ex cathedra, without providing any explanation as to why.

Our desire to discourage this practice is motivated by accessibility concerns – screen readers and other assistive tech tend to treat link and button elements differently, regardless of visual styling (which some users may not see).

But as you say, there may be reasons to do this in Wikitext if editors need this functionality and have no other way to implement it sans JS, etc. In that case I think we'd want to ensure that any markup which was produced by such a parser function was as accessible as possible. This might involve use of the role attribute, aria-label, etc.

I think we need to do a little more investigation before committing to a solution here. There are a lot of questions to consider, such as:

• Where should we draw the line between "content" and "interface"
• Security considerations
• How can template/wikitext authors use these features in an accessible way
• What use-cases do we need to support (thanks @Xover for the link, that's helpful).

This is something I'm hoping my team can devote more time to in the coming months, after we get the 1.0 release of Codex out the door later in October.

Change 963840 abandoned by Jdlrobson:

[mediawiki/core@master] Implement <mw-button> tags in wikitext for Codex button

Reason:

Will post some thoughts on Phab shortly.

https://gerrit.wikimedia.org/r/963840

I looked into usage of the classes. It seems that mw-ui-button is the only component in MediaWiki Ui that's actually used on wikis.

• There are 9,447 usages across wikis (excluding .css/.js and subpages)
• 4719 of these relate to "Click here to vote now" used for picture of the year:
  
  e.g. https://commons.wikimedia.org/wiki/User_talk:Ojph25
• 302 of these are communications with call to action for desktop improvements https://af.wikibooks.org/wiki/Wikibooks:Gebruikersportaal#Our_plan
• When you limit this to non-talk page namespaces the number reduces to 1,517 usages
• of those 282 relate to desktop improvements call to action)
• 54 relate to uploading photos for Wiki loves monuments (https://commons.wikimedia.org/wiki/Wiki_Loves_Monuments_2023_in_the_Igbo_Community)
• In the template namespace there are 486 usages.
  • The most common usage is a template called Template:ClickableButton. I couldn't find many usages of the templates that did exist. I didn't check them all but most of those templates had less than 50 usages. To take one example https://www.mediawiki.org/wiki/Special:WhatLinksHere/Template:Clickable_button is used to document the publish button(not sure why an image is not used instead) and it's used for "Subscribe to newsletter" and similar calls to action on various team pages.
• In all situations if these buttons degraded to links there would be no impact on accessibility or functionality, although I imagine as soon as a community member feels they need to have a call to action in a template they will be looking for some direction around how to do that.

From what I'm seeing the common theme for using a button is a message with some kind of prominent call to action. https://www.mediawiki.org/wiki/Growth/Communities is a really good example of that use case (used many times over). [If anyone has any compelling and explicit examples of usages of buttons outside the call to action I'd love to hear about them]

None of the existing usages on wiki feel like a true button to me (for the reasons @egardner gives above), and seems problematic (the security one is very real - https://en.wikipedia.org/wiki/User:Jdlrobson/demo_of_security_issue_with_mw_ui_button).

Although it's not my call to make, and having thought about this quite deeply since I wrote the ticket, personally, for the time being I'd leaning towards us not introducing any method for making Codex usable in templates and instead I would suggest MediaWiki provides a component explicitly for in article calls to action (either a separate component in Codex land or something that lives outside of it).

Hope this is helpful.

In T346469#9287891, @Jdlrobson wrote:

From what I'm seeing the common theme for using a button is a message with some kind of prominent call to action. https://www.mediawiki.org/wiki/Growth/Communities is a really good example of that use case (used many times over). [If anyone has any compelling and explicit examples of usages of buttons outside the call to action I'd love to hear about them]

This is the predominant use I have seen. Probably the other one is a menu like with User:Levivch/Help that is half a sandbox to the incident report system being built so far as I understand. IDK how prominent that use is currently.

Hello! We use buttons in such cases and it also seems to me that 90% is a “call to action”, if I understand what you are saying correctly.

https://ru.wikipedia.org/wiki/Справка:Введение_в_Википедию
https://ru.wikipedia.org/wiki/Википедия:Мастер_статей
https://ru.wikipedia.org/wiki/Википедия:Форум/Помощь_начинающим
https://ru.wikipedia.org/wiki/Шаблон:Добавить_тему

https://ru.wikipedia.org/wiki/Участник:Taifun21
https://ru.wikipedia.org/wiki/Википедия:Оценка

Edited: You also can see buttons under edit's summary - https://ru.wikipedia.org/w/index.php?title=Вотивкирхе&action=edit

Another use case: referring to core/extension UI elements in user documentation and messages. I just had need to update a MediaWiki:Newarticletext message to refer to two specific UI elements provided by a WMF-deployed extension as brief instructions for inexperienced editors.

The existing text there used images, and was half a decade out of date. I could screenshot myself images of the UI elements, but then I'd just create the same problem (images are comparatively hard to update). Being able to stick a couple of spans with the right classes in there and get a version that will keep working until Codex is replaced sometime in 2034 or so would be awesome.

For this use case I don't need any interactivity (not even a link, and in fact raw a tags don't work / aren't permitted in that message), and it would be better if this didn't behave like a button at all (no hover states etc.) just look like one.

In T346469#9287891, @Jdlrobson wrote:

I looked into usage of the classes. It seems that mw-ui-button is the only component in MediaWiki Ui that's actually used on wikis.

I wouldn't blindly use that as the scope of what's needed / wanted. If well-supported and stable Codex components are made available for in-wikitext uses it is likely that they would be used more, e.g. for stuff such as what I outline above. Deciding on a few that it is sustainable / reasonable to explicitly support for this kind of use is also going to communicate better that reverse engineering some random set of classes that happen to work does not mean they will be supported going forward; and channels requests for additional components through a more manageable "request it in a Phab task" flow.

In T346469#9343087, @Xover wrote:

I wouldn't blindly use that as the scope of what's needed / wanted. If well-supported and stable Codex components are made available for in-wikitext uses it is likely that they would be used more, e.g. for stuff such as what I outline above. Deciding on a few that it is sustainable / reasonable to explicitly support for this kind of use is also going to communicate better that reverse engineering some random set of classes that happen to work does not mean they will be supported going forward; and channels requests for additional components through a more manageable "request it in a Phab task" flow.

I agree, I would love to use colors variables in TemplateStyles or general styles to Cards and Tabs.

Did something happen and the mw-ui-button styles were excluded from MediaWiki?
https://ru.wikipedia.org/wiki/Заглавная_страница (If there are styles, then look in the anonymous version)

The auto-loading was disabled in mainspace in 2a3ed74cbe9e, yet again forgetting about the fact that most main pages are in mainspace, and main pages are likely to require these styles… The commit message also states that only 81 pages are affected, but it doesn’t state how this number was calculated (were templates used in mainspace considered?), nor does it state whether wikis on which those 81 pages are were contacted.

In T346469#9411227, @Tacsipacsi wrote:

The auto-loading was disabled in mainspace in 2a3ed74cbe9e, yet again forgetting about the fact that most main pages are in mainspace, and main pages are likely to require these styles… The commit message also states that only 81 pages are affected, but it doesn’t state how this number was calculated (were templates used in mainspace considered?), nor does it state whether wikis on which those 81 pages are were contacted.

Thanks for investigation!

While drafting T182050#9411609, I ran into an interesting example: https://uk.wikipedia.org/wiki/Чорне_море#Основні_миси. There are three buttons on the map, which are <span class="mw-ui-button mw-customtoggle-*">s, i.e. MediaWiki UI buttons that function as toggles for mw-collapsible elements (mw-collapsible is provided by MediaWiki core). While they have problems (they should rather be checkboxes, not buttons; and they rely on non-unique HTML IDs), I hope they will continue to be supported in some way, as they are indeed interactive elements, so using an interactive-element-like design is okay, and they don’t send users inadvertently to third-party sites (they don’t send them anywhere).

While limiting the usage of mw-ui-button in the article namespace we discovered various pages on metawiki and mediawiki.org were using Template:Clickable_button_2 for example the community wishlist. I've since updated these templates to not rely on MediaWiki UI and instead use Module:Clickable_button_3.

I do think regardless of the decision here, it would make sense for projects to make preparations over the next few months to move to similar templates. If a decision here is made to support a Codex-built button, a template will still be needed, so having one ready to go would make any future migration easier.

Why? Why do you want to duplicate everything on-wiki, and make the styles inevitably go out of sync? And why do you do so without even replying to my concerns in T346469#9171180? My opinion hasn’t changed since September: this is the worst possible solution.

Change 985150 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] Skin: Restore autoloading of mediawiki.ui.button styles

https://gerrit.wikimedia.org/r/985150

Change 985032 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@wmf/1.42.0-wmf.10] Skin: Restore autoloading of mediawiki.ui.button styles

https://gerrit.wikimedia.org/r/985032

Change 985032 merged by jenkins-bot:

[mediawiki/core@wmf/1.42.0-wmf.10] Skin: Restore autoloading of mediawiki.ui.button styles

https://gerrit.wikimedia.org/r/985032

Change 985150 merged by jenkins-bot:

[mediawiki/core@master] Skin: Restore autoloading of mediawiki.ui.button styles

https://gerrit.wikimedia.org/r/985150