@CCiufo-WMF We've talked about this in second-last engineering enclave and had agreement there. The current behaviour makes instant validation feedback impossible in Codex, see both error and warning states. cc: @egardner

@TheDJ I think this should be done at library level. Team discussion result pending.

I'd also consider if skins using MediaWiki skin variables were better off handling an alias for tokens like color-link as aliases already in core's default.

fyi, @GauriGupta told me in a personal email that they gonna will work on the patch next day(s).

Thanks for guiding us through the current implementation earlier @lwatson
Two comments from a usability perspective:

1. 'yes' and 'no' are never advisable labels for Buttons. The label should state what it's doing not which answer it provides. So in the first example above, it'd be advisable to call them 'Backport' and 'Cancel' instead. This helps users quickly orient and also possible AT users.
2. An overflow menu for just two items is also questionable. Wouldn't it be faster usable to move the two items out into the main view?

Hi @GauriGupta! Am I assuming right, that you've run out of time to continue working on this? If we won't hear back in the next 24 hours from you, I'd take the patch and finalize it with you tagged as co-author.

@DTorsani-WMF Indeed. This looks unclean and faulty to me. But in all honesty I might be too old-school here when I compare it with a number of macOS menus end of 2024. 🙂

Blocked on T381542: icons: SVGO change has unintentionally and unnecessarily increased dist SVG sizes.

@mwilliams This sounds like reasonable next steps to me. 👍🏼
All of your arguments together with the better scalability of a spinner and clearer universality (inspirational … is still a Latin character (combination) after all. Compare https://hyw.wikipedia.org/wiki/%D5%8E%D5%A5%D6%80%D5%BB%D5%A1%D5%AF%D5%A7%D5%BF or https://zh.wikipedia.org/wiki/%E5%8F%A5%E5%8F%B7 or https://or.wikipedia.org/wiki/%E0%AC%AA%E0%AD%82%E0%AC%B0%E0%AD%8D%E0%AC%A3%E0%AD%8D%E0%AC%A3%E0%AC%9A%E0%AD%8D%E0%AC%9B%E0%AD%87%E0%AC%A6} makes spinner an advantageous choice.

The padding change results in this, which is design-wise problematic:

From our engineering enclave meeting earlier today: This seems like a reasonable addition to our toolset. But some questions were raised:

• which payload limits really matter?
• how much is acceptable?

Another use case: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/1099038/1/app/src/lib/mediawiki.ui/components/MWDialog/MWDialog.vue

@Jdlrobson Just to be clear, #mw-teleport-target is _currently_ featuring .content class in this view.

This looks like a general, several side-effects causing unspecific class .content ul lingering into the CdxMenu styles, similar issues have been needed to fix before, f..e T321563:

Tag patch was submitted at https://gerrit.wikimedia.org/r/c/design/codex/+/1098158

@GauriGupta Do you have time to finalize the work on this in the upcoming two weeks?

I'd suggest to reopen this specific task for one reason:
While Codex is used in more and more places, it's still minority against OOUI interfaces. And specifically with error/destructive colors which are signals for some of the most important user decisions, we shouldn't confuse users with different shades facing such decisions.
For minimizing confusion and reducing possible user support issues, I'd suggest to align OOUI with these amended colors.

@lwatson Very nice IMHO and a real interface improvment, thanks! :)
Curious what others think…

@DTorsani-WMF One thing I've been musing together with @lwatson about is the redundancy (and prominence) of the labels per Card.
In my opinion the Card has here a tougher stand vs a tabular presentation.
I'd in any case consider to remove the labels from all but the first and last card per view to focus more on content and reduce redundancy/noise. What's your take?