There are the "quiet" buttons too ("frameless" in OOUI), which I personally think useless, but YMMV.

https://commons.wikimedia.org/wiki/Template:Clickable_button isn't even using mw-ui- classes, I think it's using some jQuery UI precursor. The problem of garish buttons for links long predates Agora/MediaWiki UI, see Template:Big Blue Button :-) .

In T116549#1755086, @matmarex wrote:

There are the "quiet" buttons too ("frameless" in OOUI), which I personally think useless, but YMMV.

Editors can add CSS class mw-ui-quiet and they will get a gray link that only colorizes on hover and click.

OOUI's frameless (framed: ""?) buttons are also quiet, but with different rollover behaviors. And neither matches the text in https://livingstyleguide.wmflabs.org/wiki/Buttons#Quiet_buttons , which says "Buttons in the quiet style do not display the Intention color or draw a button boundary unless the user interacts with them via hover or focus." I don't see a button boundary on hover/focus/click in either toolkit.

I proposed supporting OOUI widgets in wikitext with T101666: Create parser tag(s) that render OOUI PHP widgets. If it were easy enough to use MediaWiki's UX elements, maybe wikis would not invent their own.

In T116549#1760785, @Spage wrote:

OOUI's frameless (framed: ""?)

framed: false, yes.

And neither matches the text in https://livingstyleguide.wmflabs.org/wiki/Buttons#Quiet_buttons , which says "Buttons in the quiet style do not display the Intention color or draw a button boundary unless the user interacts with them via hover or focus." I don't see a button boundary on hover/focus/click in either toolkit.

Yeah, I don't think showing the button border on hover was ever implemented. OOUI frameless buttons used to be gray until hovered, but that was changed per T108086. I don't think anybody is still reading or updating any of the numerous living style guides that were created (maybe other than you :) ).

That might work, yes.
The https://outreach.wikimedia.org/wiki/Education page already uses the green button style, for an example.
Though ideally we'd provide a style that isn't used in (ambiguous with) the default site UI.

Yes, those 2 bulletpoints sound like a clearer description of the overall request. :-)

Just simple quick note - the easiest way, how to disallow people semantically incorrectly abusing built-in styles is to sanitize relevant classes. In this particular case, trim all mw-ui-* and oo-ui-*.

In T116549#2340089, @Danny_B wrote:

Just simple quick note - the easiest way, how to disallow people semantically incorrectly abusing built-in styles is to sanitize relevant classes. In this particular case, trim all mw-ui-* and oo-ui-*.

If I understand correctly, that sounds like what one dev wrote to me over year ago: "this is SPECIFICALLY why I was trying to restrict the usage of these to <a>, <button>, and <input> tags" - I think something like that would be good, in combination with the outcome of this task, to prevent user confusion.

In T116549#2340092, @Quiddity wrote:

In T116549#2340089, @Danny_B wrote:

Just simple quick note - the easiest way, how to disallow people semantically incorrectly abusing built-in styles is to sanitize relevant classes. In this particular case, trim all mw-ui-* and oo-ui-*.

If I understand correctly, that sounds like what one dev wrote to me over year ago: "this is SPECIFICALLY why I was trying to restrict the usage of these to <a>, <button>, and <input> tags" - I think something like that would be good, in combination with the outcome of this task, to prevent user confusion.

That actually wouldn't not cover everything, since the parts of OOUI are also classes for generic wrapper tags (div/span) which are permitted in wikitext, so those would remain abusable.

From task description, I'm not sure anymore, if our components don't have all the use cases covered. Color palette seems covered now.
Most open questions are around a tab-like interface, not a certain color emphasis.
If something should be a button versus a normal link, that's an issue with the editors trying to put too much visual emphasis on too many elements of the page, not sure how much we can cover this as technical solution versus trying to clarify user-interface design and patterns.

I don't think the task description as is provides a clear solvable problem statement right now, it should either be declined or slimmed down.

@Volker_E to clarify my intent in filing this task: I'm hoping for:

1. Official documented recommendations to NOT re-use UI-elements outside of their intended use-cases (as UI-elements) except within documentation - i.e. "Templates should not mimic the style off these buttons, because [...]."
2. Ideally, if there is a clear need for Templates (and images) which do something similar but distinct, then Design Team could help create those.

E.g. I just saw this related example, where someone has chosen to use Images of the "MediaWiki checkbox" as part of a standard page design. Hence there are now hundreds of pages that look like this, with elements that look as if I can click them. And anyone who does click them, will get sent to the file page, and thus slightly mistrust clicking on actual checkboxes in the future.

• Example: https://wikimania.wikimedia.org/wiki/2023:Program/Submissions/Helping_Wikisource_recognize_handwritten_documents_-_WVZNL9#Further_details
• Proliferation: https://wikimania.wikimedia.org/wiki/File:MediaWiki_checkbox_ticked.svg#filelinks
• Origin: https://wikimania.wikimedia.org/wiki/Template:MediaWiki_checkbox -- I/we/you could change the image used there, but it would greatly help to have documentation to point to, for the rationale of the edit.