I've submitted our session proposal as T333611: [Session] An introduction to Codex: the design system for Wikimedia

I've submitted a PR to the Citizen skin: https://github.com/StarCitizenTools/mediawiki-skins-Citizen/pull/606

There's also https://gitlab.wikimedia.org/repos/abstract-wiki/wlh as a working example

@egardner points out we can use https://github.com/egardner/codex-starter as a starting point and adapt it to be an extension

@egardner points out we can use https://github.com/egardner/codex-starter as a starting point, it probably has most of what we need already

Thanks for finding this! I think the responsible commit might be this one, which appears to add tests in directives-bubbling.less. It looks like the commit that follows it may be related too. I found some of these pieces while trying to fix this, but this should give a better picture of the changes we need to port.

In T319064#8280624, @Izno wrote:

overrides

Probably https://global-search.toolforge.org/?q=Creative&namespaces=8&title=Wikimedia-copyright is the majority if not entirety

In T296689#7825357, @Catrope wrote:

Reviving this old task with some thoughts about what it would take to have more than one theme in Codex:

In the tokens package, we would have to:

• Add a theme-foo.json file in codex-design-tokens/src/, whose tokens have the same names as the ones in theme-wikimedia-ui.json but different values
• Configure Style Dictionary to build dist/theme-foo.{css,less,scss} files using the tokens from theme-foo.json instead of the ones from theme-wikimedia-ui.json.

To preserve the historical record, I don't want to edit this comment from almost a year ago, but I should add here that I've since realized that it's not this simple. T325237#8700501 goes into a little more detail, but briefly: it's not the case that to make a different theme, you would only have to change the values in theme-wikimedia-ui.json but not those in codex-base.json. The filenames imply that, but it's not true. We would need to do more to figure out how this would work, and how we should organize our files and directories differently.

In T325237#8689509, @egardner wrote:

In the future, we would like to add these "neutral" values as a theme in Codex, so that the defaults file can just import that theme, but that's out of scope for this task.

If this really is the better solution, should we consider just going ahead and doing this now?

In T325237#8689504, @egardner wrote:

Is there a MediaWiki page that documents the existing skin variables system (prior to the changes we are proposing for better Codex integration)?

In T330803#8689602, @AnneT wrote:

A flaw of option 1 is that you must bind :disabled to both the outer Field and the inner Fields; the outer Field will not tell the inner Fields whether they should be disabled (although we can probably figure out a sensible way to do this).

We could use provide/inject so that a nested Field can find its parent Field and disable itself if the parent is disabled. We could also explore using this technique to communicate state between Field components and the input components inside them, although that would require a bit more complexity, as we'd have to duplicate that logic in TextInput, Checkbox, Radio, etc (we could wrap it in a composable, but still, all those components would have to know about it).

@Volker_E Are you happy with the neutral values in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/886929/ , or does more work need to be done there?

Looks like these icons still need to be added to OOUI?

In T328163#8644493, @sbassett wrote:

Ok, thanks for the update. I think this would likely make this security review a bit lower in priority for us since, for now, this extension will only ever live on beta and the risk for that has already been accepted by a WMF manager/director.

I think this is happening because the import in NoEditsDisplay has one ../ to few. From mediawiki/extensions/GrowthExperiments/modules/ext.growthExperiments.Homepage.NewImpact/components/NoEditsDisplay.vue, the import path ../../../../resources/lib/codex-design-tokens/theme-wikimedia-ui.less resolves to mediawiki/extensions/resources/lib/codex-design-tokens/theme-wikimedia-ui.less , which doesn't exist. You need one more ../ to make it work.

The attached patches implement my proposal. They don't exactly do what the task title asks for, but they solve the same problem: remove 84 of the 94 deprecated tokens from Codex, so they can later be moved into wikimedia-ui-base instead.

For deprecated tokens that are just aliases of non-deprecated tokens, I think it would make the most sense to remove them from Codex completely, and just provide those aliases in wikimedia-ui-base. For deprecated tokens that have unique values (values different from any non-deprecated tokens), I think it should keep them in Codex as deprecated tokens.

PatchDemo issue: https://github.com/MatmaRex/patchdemo/issues/531

It looks like this only happens when code is wrapped in a ```less or ```css block. The formatter for ```vue is much less opinionated, and just breaks lines that are too long.

We could use the code groups feature in VitePress to build something like this:

I favor #3, because we don't need an NPM-compatible module name in this context, and I think #1 and #2 would be confusing because they pretend to be NPM-compatible but aren't. But that's not a strongly held opinion, and I'd love to hear other opinions or other naming suggestions.

In T330349#8641092, @Tacsipacsi wrote:

if setting ['type' => 'script'] is appropriate for .vue files, enabling Vue is as easy as changing the regex in MediaWikiGadgetsDefinitionRepo.php (which doesn’t necessarily mean that Vue actually works, just that the file extension barrier is removed).

['type' => 'script'] is not the appropriate type for .vue files, it's ['type' => 'script-vue'] (this matters because .vue files need certain transformations, and can also contain styles in addition to script code). But that shouldn't be too hard to address, we'd probably just need to add another category of resources to the Gadget class, like we did for JSON files ('datas' at rEGAD includes/MediaWikiGadgetsDefinitionRepo.php:272-282 (at 7793a9475f18) and getJSONs() at rEGAD includes/Gadget.php:334 (at 7793a9475f18))

In T328163#8590059, @sbassett wrote:

I've added this exception to our risk register. Is this ever being planned for a production deployment? I think we should still perform a security review of the code, regardless, I'm just less clear after reading this language within the description: "Only used for testing, and only proposed for deployment to the beta cluster, not to production wikis."

In T327499#8614601, @AnneT wrote:

@matmarex thanks for the suggestions! I had forgotten about the mousemove event.

mousemove does indeed provide the ideal UX here, in that it avoids highlighting an item that happens to be under the cursor when the menu opens, but starts highlighting items as soon as the mouse moves. My only concern is that it gets triggered with each mouse move—I wonder if there's a performance concern with the mousemove handler being called over and over if the mouse is moved a lot? cc @Catrope