User Details
- User Since
- Oct 8 2014, 8:32 PM (442 w, 2 d)
- Availability
- Available
- IRC Nick
- RoanKattouw
- LDAP User
- Catrope
- MediaWiki User
- Roan Kattouw (WMF) [ Global Accounts ]
Today
Yesterday
Thu, Mar 30
I've submitted our session proposal as T333611: [Session] An introduction to Codex: the design system for Wikimedia
Tue, Mar 28
I've submitted a PR to the Citizen skin: https://github.com/StarCitizenTools/mediawiki-skins-Citizen/pull/606
Mon, Mar 27
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
Thu, Mar 23
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.
Wed, Mar 22
Thu, Mar 16
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.
Wed, Mar 15
Tue, Mar 14
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).
Fri, Mar 10
Thu, Mar 9
@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?
Wed, Mar 8
Tue, Mar 7
Mon, Mar 6
Sat, Mar 4
Thu, Mar 2
Mar 1 2023
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.
Feb 28 2023
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.
Feb 27 2023
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.
Feb 24 2023
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.
['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))