Background

@DTorsani-WMF has been working on a comprehensive update to Codex's typography system. One aspect of this has been an exploration of whether we can support different font sizes and typographic scales through the use of different "font-size modes", in a way that mirrors what we are already doing for color schemes.

The goal of these different font modes would be to preserve intentional design decisions around font sizes, line heights, and typographic scale while also supporting different user-defined "base font sizes". This could let us support different default font sizes in skins (Vector vs Minerva, etc) without resorting to the "legacy" build hacks we have used in the past. But such an approach could also support client-side font size switching in response to user preferences (something the Codex legacy build could not accommodate).

Derek has proposed a system where font-size tokens would indicate relative size values, but the final size in pixels would be determined by the mode currently in effect. Here's a quick illustration:

Line height values would vary across modes in a similar way. The full proposal can be read here.

Different skins could even default to different "modes" by default.

Next Steps

We need to set up a working prototype of this system in use (for both typographic elements as well as Codex components) to refine and evaluate it.

The most straightforward way to demonstrate these different values in use would be do do the following:

• Set up a new stand-alone page in the Codex sandbox (not the regular docs site)
• This page should be kind of like a type specimen (full of different typographic examples), but it should also include some components
• The page should include a client-side font-mode switcher element to allow viewers to see changes in real time

As with the color modes, we would build out font-size modes as supplemental stylesheets that override the values for a subset of CSS custom properties for the relevant tokens. One mode would always be applied by default. CSS custom property definitions would probably also define a fallback value to be safe.

Acceptance Criteria

• Add/update token definitions per the font modes proposal
• Update the tokens build system to produce different font modes, with the "standard" mode as the default
• Build a stand-alone Sandbox demo page that can showcase different typographic arrangements
• Add a client-side font-size switcher UI to this demo page
• Publish this page or make it available as a deploy preview for further design review

---

Prototype Findings

There is now a basic prototype which demonstrates font-mode switching, based on a series of unmerged patches. The live demo can be seen here: https://1042381--wikimedia-codex.netlify.app/sandbox/

The patches can be found here:

• Introduce new font-size and line-height tokens
• Introduce "small" font size mode

Issues and considerations

• The first patch sets up new option and decision tokens to represent the font sizes and line heights as precise pixel values (output is still converted to rems at the end of the build process, but we can ignore that fact for now). We already have tokens for both font-size and line-height which work differently, so to minimize the risk of breaking changes I am proposing that we create entirely new tokens here. That will make it much easier to migrate existing tokens over (it's not always going to be a 1:1 correspondence).
  • However, introducing new tokens means we need to come up with new token names. We already have tokens named things like small, medium, large, etc. If we want to create new tokens which don't collide with those values, we need to come up with a new naming scheme. For the prototype I've opted to use the terms title, heading, subheading, body, and caption; we don't need to keep these exact names but we should think carefully about what we might use.
• As you can see in the first patch, we will have to go in and change tokens in most/all existing components to implement this plan. This will require extensive review to ensure that everything is done correctly.

Open Questions

• Do we want icons to also participate in the size change? Currently they do not.
• This approach would allow two different parts of a wiki page (say, page sidebar vs main page content) to set two different font modes. Indeed, it looks like this is the path that the Web team is going to take in Vector. This raises the possibility that we could have Codex components appearing in two different parts of the same page with two different font sizes. Do we want this? (genuine question – I'm not sure if this is a feature or a bug).

Alternative approaches

This prototype represents one way that we can solve our age-old "font size problem" on the Wikis – the two most popular skins (Vector and Minerva) use different body text sizes, but we don't want to maintain two different sets of component styles which are skin-specific.

The other potential solutions we could pursue here are:

1. Do nothing – Codex components would always appear the same size (based on a 16px font size) everywhere. Article body text size may change based on skin or user preference but we would just consider Codex components to be independent of this.
2. Use media queries – if the goal is to provide larger text, buttons, etc to users on small screens, we could just use media queries to swap out tokens where appropriate.

Next steps

We need to decide how to move forward here before we do additional work. Any feedback on this approach (either design or implementation) would be appreciated.