Feedback that would be helpful:

• What do you think of the proposed solutions?
• Are there other potential solutions?
• Does anything need to change on the Figma end, in addition to any changes we might make on the implementation end?

My personal preference is for option 1. I think we could avoid the Vector/Minerva and desktop/mobile names by using the term "legacy mode". This is a concept that is already being proposed in this change, and it would go along with dark mode. We could have a control for each demo that let you choose the mode (legacy or dark, or maybe even dark+legacy?) along with the direction. This way it also wouldn't really be MW-specific, or at least wouldn't introduce any new MW-specific things: we'd be exposing the same modes that already exist in the tokens package. We would need to make some other technical changes (mainly using CSS variables for the affected tokens), but for the most part we're already planning to make those changes (or at least similar ones) for other reasons.

I don't like option 2 as much, because it would be harder to keep the demos in sync. The best way I can think of would be for Codex to build either the sandbox or a combination of all the demos (gathered in an automated way so that we can't forget to manually update something) as a JS file rather than an HTML file, make that part of the Codex release tarball that is published to NPM, and have VueTest just wrap that in a simple special page (or maybe even put a Special:CodexTest page in MW core?). That way things would be updated automatically, you'd always see the demos that correspond to the release of Codex that is being used in MW, and if you needed to see the demos for a more recent unreleased version you would use T314507 (or its current workaround). The downside in my mind would be that this file would be part of the release that is published to NPM, even though it's really only intended for testing purposes, but I acknowledge that's more of a "philosophically not ideal" thing than an actual practical problem.

I think option 2 is the "correct" way to do this. The 14px context is specific to Vector, so I think the demos of our components in a 14px context should just be displayed in Vector itself. I think this is important for 3 reasons:

1. Philosophical reason: it keeps Codex, including the docs site, skin-agnostic. Having a font-size switcher on the docs site seems cluttered and confusing to me.
2. Technical reason: we are currently discussing making major changes to the way we support using Codex in a 14px context, including shipping a single font-size mode and enabling users to override font-size tokens in their projects (e.g. in Vector). I don't think we should build a font-size switching system on the docs site that might be subject to change, or might not exactly replicate what happens in Vector, which could increase the risk of regressions or unexpected results onwiki.

Keeping the demos in sync is a real challenge, and it didn't work well with VueTest. That said, I think our time would be better-spent creating a system for keeping at least a set of demos in sync and displaying them on some test wiki, rather than making what I would consider hacky changes to our docs site.

In T359884#9643547, @AnneT wrote:

2. Technical reason: we are currently discussing making major changes to the way we support using Codex in a 14px context, including shipping a single font-size mode and enabling users to override font-size tokens in their projects (e.g. in Vector). I don't think we should build a font-size switching system on the docs site that might be subject to change, or might not exactly replicate what happens in Vector, which could increase the risk of regressions or unexpected results onwiki.

I think this depends on which technical approach we end up going with: if we build support for a 14px context into Codex as a legacy mode (similar to how dark mode would work), then I think it makes sense to have a way to exercise that built-in support in Codex itself. But if we keep it out of Codex and it lives entirely in Vector, then I agree that it doesn't make sense to have demo tools in Codex for something that doesn't live in Codex.

Keeping the demos in sync is a real challenge, and it didn't work well with VueTest. That said, I think our time would be better-spent creating a system for keeping at least a set of demos in sync and displaying them on some test wiki, rather than making what I would consider hacky changes to our docs site.

I think this also depends on the technical approach for supporting 14px: if it is a mode just like dark mode, then exposing it on our docs site wouldn't be hacky if we exposed it in the same way as dark mode, and we'd have to build a light/dark switch anyway. But if it's a Vector-specific thing, then it would make more sense to demonstrate it in MediaWiki.

Change #1123662 had a related patch set uploaded (by Anne Tomasevich; author: Dtorsani):

[design/codex@main] docs: Add font mode selector and adjust type page

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

Change #1124530 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] [proof of concept] Add an appearance menu to the docs site

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

I've worked with Derek to create a proof of concept that adds a new ToggleButton and Popover to configure appearance items (color mode and font mode). This means no longer using VitePress's color mode switcher, and shifting the items in the main nav a bit. We decided this was the best solution, rather than adding a new font mode picker without changing anything else. Doing that also would have required moving around the main nav items, so creating a more final solution allowed us to develop the best design and only change the nav styles once. The old VitePress color switcher also did not use Codex components and was not ideal from a design standpoint, so our approach fixes that.

One shortcoming of my patch is that your color and font mode selections will not persist if you open the site in a new tab or window. We could store these things in localStorage to ensure that they persist in the same session.

Stalled pending T387778 being merged

Change #1124530 merged by jenkins-bot:

[design/codex@main] docs, icons: Add an appearance menu to the docs site & 'configure' icon

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

Change #1139942 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] Update Codex from v1.23.0 to 2.0.0-rc.1

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

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/f82f2e0c2b/w/

Test wiki created on Patch demo by 1Esk19 using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/ffa0e13429/w/

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/f82f2e0c2b/w/

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/e49103389b/w/

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/e49103389b/w/

Change #1139942 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.23.0 to 2.0.0-rc.1

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

Test wiki on Patch demo by 1Esk19 using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org//wikis/ffa0e13429/w/