Our night mode implementation is evolving quickly. We've implemented two changes this week that will have an effect on how we integrate the Codex experimental build.

In Map color-based skin variables to CSS variables we've implemented a Less <-> CSS variable referencing strategy in the Minerva skin ie: @color-base: var(--color-base);. The Codex experimental build does this for us, yay! That should mean we get to delete all this.

Because of this approach, CSS variables now get propagated across the wikiverse (to core and extensions) giving us at least partial night theme support across extensions without having to actually modify them (largely thanks to @Volker_E 's work in implementing these variables everywhere 🎉). However, we still need to use an invert() strategy in some cases. When we do that, we want to make sure that the element we're inverting use the light-theme variables.

To accomplish that, in this patch we did this:

:root, 
.skin-invert {
--color-base: lightModeColor;
}

The Codex experimental build doesn't come with that .skin-invert class on the :root element (and I don't think it should).

So in order to add it to the :root block, we should use the Less extend() functionality on the .skin-invert selector like so:

If you need Codex to produce the list of variables without them being wrapped in a :root {} block, we may be able to do that. I think we may need to do something like that anyway in the near future, since we plan to put the night mode color palette in the codex-design-tokens package and have Minerva import those values from there, rather than putting those values in Minerva itself.

Change 1006985 had a related patch set uploaded (by Jdrewniak; author: Jdrewniak):

[mediawiki/skins/MinervaNeue@master] [WIP] Integrate experimental build of Codex design tokens

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

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

Change 1006985 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Integrate Codex experimental design token build

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

AC5

@Edtadros the bug only relates to errors in the dialog window. It can be found in the more menu - I can confirm it's a pass!

Looks like the experimental Codex styles are working as intended.

There is one small issue with the CSS-only Select (dropdown) component where the little icon won't invert its color yet. We have T358703 to track it and there is a patch with a workaround solution up now.

I'm sure that you will notice other small issues with Codex (components not using the right tokens or the right tokens not being exposed in the first place). Just let us know and we can get fixes into an upcoming Codex release.

As part of this ticket, I wanted to leave a comment documenting any edge-cases or workarounds I ran into with the initial implementation.

Implementation feedback

Using SkinCodexThemes in skin.json - It looks like adding the following lines in skin.json "SkinCodexThemes": {"minerva": "experimental"} loads the CSS variable aware version of Codex, but it doesn't load the CSS variables themselves. This actually works to our advantage since we need to explicitly import the experimental theme in order to modify the :root selector, but I'm just pointing out that it wasn't obvious to me until the very end of this implementation (when we realized the RelatedArticles extension didn't appear in night mode without it).

modifying the :root selector - As part of the night-mode feature, we're developing affordances for opting out of night-mode using css classes, i.e. .notheme and .skin-invert. We need to make sure these classes are always in day-mode and recieve the day-mode variables. To do this, we group these classes with the :root selector using the Less extend function: CSSCustomProperties.less#31:

.skin-invert:extend(:root), 
.notheme:extend(:root) {}

Producing the following output:

:root, 
.skin-invert, 
.notheme {...}

This works for us. I'm noting it since it depends on the Less :extend() feature, which is not commonly used.

Integration with the mediawiki.skins.variables system - The functionality of the experimental build that references Less variables to CSS variables: @color-base: var( --color-base ); is very valuable for us at a skin level because it lets us propagate the CSS variables to extension and core, thereby adding night-mode support, without even having to touch those repositories. To make this work however, we have to using the Less @import (reference) feature mediawiki.skin.variables.less#21 So that the CSS :root selector is not duplicated anytime someone uses @import mediawiki.skins.variables.less.

@import ( reference ) 'mediawiki.skin.codex-design-tokens/theme-wikimedia-ui-experimental.less';

That imports the variables and spreads them across the ecosystem, while omitting the CSS :root block. This works, but it's also an uncommon technique. It would be preferable if the CSS variables and the Less/CSS variable conversion were split into two separate files.

Adding custom CSS variables to the :root block - We discovered the need to add Minerva specific CSS variables for custom colors. We achieved this by doing the following. CSSCustomProperties.less

:root {
	--minerva-diff-addedline: @color-success;
	--minerva-diff-deletedline: @color-destructive;
	--box-shadow-color-drawer: rgba( 0, 0, 0, 0.35 );
}

this mix of CSS variables and Less variables looks a bit odd, and it's probably something we should reconsider in the future.

Silent failures with missing CSS custom properties - Not necessarily related to the Codex experimental build specifically, more so working with CSS custom properties in general. Before the Codex experimental build was released, we had converted all our Less variables into CSS custom properties in Minerva. This included some non-standard variables which I accidentally deleted when integrating the experimental build. This lead to some high-priority bugs in which link colors were black instead of blue because their colors were assigned to css variables that didn't exist, e.g: var( --link-color--visited ). CI passed on these patches, and I couldn't find any way to enforce the existence of CSS custom properties through StyleLint. If these were Less variables, they would have failed compilation and the errors would be obvious. I ended up writing a Gist that tests the CSS output with PostCSS for undefined CSS variables. This might not be specific to the Codex build, but it's something I'm still wary of moving forward with CSS custom properties. Maybe using the referenced Less variables instead is the way to avoid this?

Test Result - Prod

Status: ✅ PASS / ❓
Environment: enwiki
OS: macOS Sonoma
Browser: Chrome
Device: MBA
Emulated Device:NA

Test Artifact(s):

QA Steps

✅ AC1: Make sure no visual regressions occur in Pixel.
n/a for production
✅ AC2: Check Special:Nearby - it should appear in a night-mode like theme https://en.m.wikipedia.org/wiki/Special:Nearby?minervanightmode=1 - it should appear in a night-mode like theme

That's fine @Edtadros - this one can be skipped in production.

In T358059#9620816, @Jdrewniak wrote:

Integration with the mediawiki.skins.variables system - The functionality of the experimental build that references Less variables to CSS variables: @color-base: var( --color-base ); is very valuable for us at a skin level because it lets us propagate the CSS variables to extension and core, thereby adding night-mode support, without even having to touch those repositories. To make this work however, we have to using the Less @import (reference) feature mediawiki.skin.variables.less#21 So that the CSS :root selector is not duplicated anytime someone uses @import mediawiki.skins.variables.less.

@import ( reference ) 'mediawiki.skin.codex-design-tokens/theme-wikimedia-ui-experimental.less';

That imports the variables and spreads them across the ecosystem, while omitting the CSS :root block. This works, but it's also an uncommon technique. It would be preferable if the CSS variables and the Less/CSS variable conversion were split into two separate files.

I've filed T360577 for this.