See also related tasks T290815: Bump basic and modern supported Android browsers to v5

See also related task T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015)

Design members had an async conversation about TypeaheadSearch which led to T297025: Design TypeaheadSearch component for Codex.

Server settings related, such URL results also in fun: https://doc.wikimedia.org/codex/main/icons/
Storing this here for a moment.

@Jdlrobson There is one more mention of IE
https://gerrit.wikimedia.org/g/mediawiki/extensions/MobileFrontend/+/1175aa5b6e261411cc0da4522a16242e22a4465c/src/mobile.startup/View.js#315

It's the 5th item at T273785: Deal with release of npm 7. If you've got LibraryUpgrader active on your repo, it will always return to package-lock.json v1, no matter if you (on npm v7) have made dependency upgrades and locally have v2 that you'll commit.

Need to put video on GDrive as too big for Phab: https://drive.google.com/file/d/1IfOoQROUnaetLOzrbrLnd0GsDhiZyseO/view?usp=sharing

Can reproduce on latest Safari. Same issue like y'day sidebar link href points for example to /codex/main/components/text-input and Safari doesn't transform to /codex/main/components/text-input.html.

@AnneT Does it work for you on Safari? It seems Chrome is behaving differently than all other browsers here.

Hi all, I've just noticed this task for the first time (no surprise having all the focus and progress on Codex over last couple of weeks).
Late comments therefore: From a design system perspective the quiet progressive button with dropdown seems the preferable choice here.
The primary progressive button would be a wrong treatment as those buttons are aimed to signify the single, primary action in a view.

The new Codex library features a different ability to icon usage and inclusion, catering to all three needs mentioned in the task description, implemented by @Catrope.

• The icon element uses SVGs fill=currentColor. With that it defaults to the wrapper HTML element's color style. And can be easily overwritten by a CSS class or even an inline style (not advised).
• The size setting is similarly easy with classes amending the min-width or width of the Codex Icon component when placed inline. See demo for an example of those inline Icons. The remaining question is if the icon should be specifically set-able or if a number of specific typography wrapper bound styles could be sufficient. Thinking of all block level elements direct icon component children here.

@Izno Several fair points. Acknowledge that the task description hasn't been outlined bullet-proof at point of writing due to time scarcity. Please note that IE9 and IE10 are though the biggest blockers from the to be updated list of basic support browsers. They have a 10+million pageviews base per day (equals ~0.05%), while for example all Android 4 comes down to 3.8 million including statistics outliers and earlier versions lower than 4.4.
They also got historically provided the largest amount of browser specific workarounds and code in MediaWiki core and beyond, with the biggest maintenance relief and performance impact in comparison to mentioned Android 4.4 or Firefox 27 to be removed from basic support (in a different task).

This will probably live in 'packages/vue-components/src/styles/mixins.less'
As we'll need to differentiate between theme and functional mixins.

Setting to “low” until component addition with usage for hidden text is requested.

To provide some extra context here on comment above,

1. gzip is taking good care of such repetitive code blocks
2. it could be considered to have a Less mixin call that outputs several callers in a combined selector

This has been accomplished in the meantime in Codex by @Catrope. No need to have this remaining open in the soon to be deprecated WVUI library.

Not sure I completely follow the task description and the problem statement here with the outlined improvements? The ComboboxWidget comes in different variants of interaction currently. Only the “filtering on input” doesn't show all values when input is already provided.
Rephrasing for myself, even if there's a value selected, focussing the input field or clicking the dropdown button would show all available options again, correct? With the selected one highlighted? As soon as keyboard input is provided the options list is filtered again?

@alexhollender I'm convinced a 'notice' type message to the user were sufficient here. Otherwise it seems more distracting from the content as it should.

It would be helpful to have a before and after screenshot in the task description.

Behavior is just true for the user menu links and not for any other links. Not even if we're providing some sort of focus for the menu item clicked, I'd see a user benefit here. If you click Watchlist and another link on the Watchlist page and then go back twice, suddenly the user menu is still open. It's more confusing than anything else IMO.

This has been resolved successfully with the decisions in the Vue.js designer workshop and developer summit and follow-up at the Vue taskforce.
Codex is the (documentation, repository) shared toolkit and component library for Wikimedia (Foundation, Wikimedia Deutschland et al.).

When working on the tokens patch, I've discovered a detail I think would still lead to confusion regarding wikimedia-codex.json + wikimedia-legacy.json:
We have a design-/theme-agnostic library “Codex” that carries theme “wikimedia-codex.json' as one of it's themes.
That's why "Wikimedia UI" still makes sense to me and makes things more obvious.

@Sarai-WMDE Yes! 1. was actually brought forward by a number of folks in recent conversations in one way or the other, for example by @amin and @Sneha,

2. is reasonable, but out of scope and also questionable for end of this quarter.

Is it necessary to have either codex- or vue- presiding components?
Do we think we might have different implementations in the same repo? Isn't components sufficient for the directory?

#2 is a no-go for Design Systems approach from my current understanding, as it would disable combining tokens and icons into a different technical implementation – think for example Apps using only tokens or a React implementation of the Design System, where tokens and icons are essential.

@karapayneWMDE jfyi @Jdlrobson is on vacation this and next week. Defer to @SCherukuwada and @nray for possible feedback here in the meantime.

In comparison, OOUI has come to these interaction elements:

We could make a quick patch release, it would currently only contain this patch. Would like to checkin with @Catrope first on the progress for https://gerrit.wikimedia.org/r/c/wvui/+/738470 as a combined patch release would be preferable. With such, it would be either end of the coming or second-next week until it's released and put into MW core to production use.

Thanks @nray! This wrong attribute has been brought over into new Codex library as well, so let's make sure, we're keeping the code in sync between those two.

Sorry, that it came late. I had a memory flash about composition-api and WVUI this afternoon after reading your comments above and search immediately brought it up.

For one, this is great progress. Also I like the idea of changing to toggle switches, as long as the update is dynamic.
From a usability perspective it would make sense for the show and hide code to be either quiet toggle buttons (not yet part of Codex) or to stay as quiet buttons with an additional icon.

Hi @valerio.bozzolan, thanks for your feedback, and even if it's critical, I appreciate the honesty and the delivery. :)
I was waiting for @lucamauri to chime in and provide a final feedback. Aware that the lastly settled on is only related to the original proposals.

In T295106#7497606, @Catrope wrote:

I figured out what the problem was: WVUI embeds the composition API plugin, which causes problems when running under Vue 3 where there's a real composition API. I have working draft patches that externalize the composition API to fix this problem. I'll get them into reviewable shape tomorrow and submit them.

Because externalizing the composition API plugin also requires a change to ResourceLoader, I've also written an alternative patch that continues to bundle the plugin with WVUI but bypasses it when it detects that Vue 3 is being used.

Updated Gerrit commit message guidelines with footer section.

Refined for unifying to docs: and tests: plural over singular for those changes.