Page MenuHomePhabricator

Tokens: Produce a "dark mode" build of Codex design tokens
Closed, ResolvedPublic5 Estimated Story PointsSpike

Description

Once a set of dark mode decision tokens exists (see T360341), we need to update the tokens build process to generate both default and dark modes side by side. All assets need to be produced in all necessary formats.

Rough outline of what needs to happen here

When T360341 is complete, we'll have a new file in the Codex Design Tokens repo called modes/dark.json or something similar. That file should contain a subset of decision tokens relating to color with alternate values (chosen from existing option tokens) suitable for use on dark backgrounds.

At that point we can produce the dark mode output by doing the following:

  • Call sd.extend() in build.js and pass in the default token files using include instead of source; then set source to an array which includes the dark mode file. This will ensure that the dark mode values override the default values.
  • Inside the config for sd.extend(), re-define the "stylesheet" platform. The files array should contain one entry, with a destination of codex-dark.css (or whatever we want to call it). We need a filter here to filter out tokens so that only tokens with "dark" in the file path (or matching some some similar rule) get included.

We may also want to rename the "experimental" CSS variables file we currently produce to something like codex-light.css – this is the default value that should be loaded alongside the experimental Less variables file.

Event Timeline

lwatson renamed this task from Tokens: Produce a "dark mode" build of Codex design tokens to [SPIKE]Tokens: Produce a "dark mode" build of Codex design tokens.Mar 18 2024, 5:16 PM
lwatson set the point value for this task to 5.
CCiufo-WMF renamed this task from [SPIKE]Tokens: Produce a "dark mode" build of Codex design tokens to [SPIKE] Tokens: Produce a "dark mode" build of Codex design tokens.Mar 18 2024, 5:16 PM
egardner renamed this task from [SPIKE] Tokens: Produce a "dark mode" build of Codex design tokens to Tokens: Produce a "dark mode" build of Codex design tokens.Mar 18 2024, 5:17 PM
egardner changed the subtype of this task from "Task" to "Spike".

Change #1013390 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[design/codex@main] tokens: Produce light and dark sets of CSS variables

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

Change #1014638 had a related patch set uploaded (by Catrope; author: Catrope):

[design/codex@main] tokens: Add Less mixin version of dark mode build

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

@Jdrewniak The patches attached to this task generate output that looks like this:

theme-wikimedia-ui-mode-dark.css
:root {
  --color-base: #f8f9fa;
  --background-color-base: #101418;
  /* ... etc  ...*/
}
theme-wikimedia-ui-mode-dark.less
.cdx-theme-wikimedia-ui-mode-dark() {
  --color-base: #f8f9fa;
  --background-color-base: #101418;
  /* ... etc  ...*/
}

Only tokens whose values are different in dark mode appear in these files.

To use these in Minerva, you could either load the .css file with a media query, or you could import the .less file and then call the mixin somewhere (the way you currently use .mixin-night-mode-palette()).

Please let us know if output like this is useful, or if you'd like it to look different.

hi @Catrope, the following sounds good:
✅ Less variables and CSS variables in separate files
✅ A dedicated night mode mixin
✅ Only includes tokens required for night mode

light mode mixin
I have a question regarding mixins. I see .cdx-theme-wikimedia-ui-mode-dark() will there be a equivalant mixin for the light theme?

Currently in Minerva, we import the CSS :root block and use the Less :extend() function to add selectors to it.
In my opinion, I think it would be clearer if we used a mixin for light variables instead.

e.g. instead of this

@import 'mediawiki.skin.codex-design-tokens/theme-wikimedia-ui-experimental.css';

:root:extend( :root ) {  👈 /* this selector is awkward */
	--minerva-diff-addedline: @color-success;
	--minerva-diff-deletedline: @color-destructive;
	--box-shadow-color-drawer: rgba( 0, 0, 0, 0.35 );
}

can we have this?

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

:root {
    .cdx-theme-wikimedia-ui-mode-light();  👈 /* a mixin would be clearer */
    --minerva-diff-addedline: @color-success;
    --minerva-diff-deletedline: @color-destructive;
    --box-shadow-color-drawer: rgba( 0, 0, 0, 0.35 );
}

This would essentially mean we would write the :root selector ourselves, which is something we need to customize anyway to provide different night mode overrides.

Change #1013390 merged by jenkins-bot:

[design/codex@main] tokens: Produce CSS vars file with overrides for dark mode

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

Change #1014638 merged by jenkins-bot:

[design/codex@main] tokens: Add Less mixin version of dark mode build

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

There is now a dark mode build in Codex, but because T360341 isn't done yet, it contains dummy values for now. We also changed the file names around:

  • The experimental files are now named theme-codex-wikimedia-experimental.css and .less
  • The dark mode files are now named theme-codex-wikimedia-mode-dark.css and .less
  • The Less mixin exported by the -dark.less file is now named .cdx-mode-dark()

I've updated the demonstration change in Minerva to account for these changes.

hi @Catrope, the following sounds good:
✅ Less variables and CSS variables in separate files
✅ A dedicated night mode mixin
✅ Only includes tokens required for night mode

Happy to hear that!

light mode mixin
I have a question regarding mixins. I see .cdx-theme-wikimedia-ui-mode-dark() will there be a equivalant mixin for the light theme?

Right now, no, but we can work on that next. I have filed T361325 for this. It's a little tentative because I'd first like to discuss whether the other DST engineers think it's a good idea, and if so, where this mixin would live. In the meantime, it's my understanding that this isn't a blocker, because the :extend( :root ) hack works for now, is that right?

Right now, no, but we can work on that next. I have filed T361325 for this. It's a little tentative because I'd first like to discuss whether the other DST engineers think it's a good idea, and if so, where this mixin would live. In the meantime, it's my understanding that this isn't a blocker, because the :extend( :root ) hack works for now, is that right?

@Catrope sure thing, not a blocker, technically both approaches get the job done, it's really just a question of where a mixin is preferable over :extend(:root).

Change #1016452 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Update Codex from v1.3.5 to v1.3.6

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

Change #1016452 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.3.5 to v1.3.6

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

Volker_E edited projects, added CSS; removed Patch-For-Review.
Volker_E updated the task description. (Show Details)