@AnneT I also wanted to point out that in addition to the state related styles, in my testing the button class doesnt style arbitrary elements correctly. I.e. this is what it looks like for a <label> element:

Basically the same problem as https://phabricator.wikimedia.org/T284273 but for <label>

@bwang Good point - we make use of several native button pseudo-selectors (enabled/disabled, active/focus/hover...) which would not work with label, and I'm assuming we'd need to explicitly set display: inline-block to cover other elements. We would either need to use an explicit class-based approach in Button or write special styles to cover other elements.

@bwang suggested a way for us to do minimal updates in Codex to allow them to achieve the right styles in Vector:

• In Codex, use :not( :disabled ) selectors instead of :enabled, which will allow enabled styles to apply to other elements. Disabled styles aren't needed at the moment, so we don't need to provide a path for that.
• In the feature using these buttons, other styles will need to be applied to get the size and spacing right

See this patch.

@CCiufo-WMF revisiting this, I did originally set the acceptance criteria to just cover making this possible, not actually providing full support within Codex itself. So resolving T284273 will resolve this task too, although we may want to consider if we do want to provide documented, full support for the checkbox hack in Codex in the future.

Thanks @AnneT! Yeah let's keep this ticket as written and hold off on the "full support" until there is a clear need.

Change 922910 had a related patch set uploaded (by Anne Tomasevich; author: Bernard Wang):

[design/codex@main] Button: Add classes to support CSS-only non-button buttons

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

Change 922910 merged by jenkins-bot:

[design/codex@main] Button: Add classes to support CSS-only non-button buttons

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

Change 927786 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/core@master] Update Codex from v0.11.0 to v0.12.0

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

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/8ca78d2715/w

Change 927786 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.11.0 to v0.12.0

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

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/8ca78d2715/w/

In T333394#9454294, @Jdlrobson wrote:

This is high from web team's side. I've added it to agenda on next web/dst sync.

The next scheduled sync is Jan 29 -- is that ok, or is it high enough to discuss sooner?

I think that's fine, but it would be good if DST could chat about it beforehand? Maybe it's something we can resolve asynchronously?

Do we really want to keep using/recommending this pattern in Codex? We were talking last week about starting to use the new <details> element more widely (and possibly adjusting our browser support requirements for basic support).

I would love to be able to leave such hacks behind in favor of clean, declarative, modern web standards.

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

[mediawiki/skins/Vector@master] POC: Express dropdowns as details/summary elements

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

It's a good question. It looks like this would be straightforward so it would be a product call - these menus are important and we'd need to think carefully about how they degrade in older browsers (it might be better to make them disappear rather than to make them always show for example).

Support looks pretty good based on who we tend to build for: https://caniuse.com/?search=details