Noting a real example to test would be Multiblocks (T387983)

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

[design/codex@main] demos: Add typography demo Sandbox page

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

I've created this patchdemo, but the Less errors documented in T389116 prevent it from being useful. Instead, you can try spinning up MediaWiki with your local version of Codex checked out to the font modes patch. You'll likely encounter some similar issues but you can fix them individually (by replacing the problematic Codex token with an equivalent em or rem value) to get Less compilation working again so you can move forward with testing.

I'll do this myself on Wednesday to test some special and article pages.

Change #1127236 merged by jenkins-bot:

[design/codex@main] demos: Add typography demo sandbox page

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

@DTorsani-WMF / @Volker_E I found a couple of minor issues with QuickSurveys, which does scale with text size since it's in the article content.

First, at the large text size, the checkbox icon looks a bit weird since the box itself does not get larger. This is because its height and width are set to font-size-x-large, which does not scale in Vector.

You can also see that the close button does not scale with the rest of the interface - it looks very small compared to the rest of the components. The reason is the same - the icon's width and height are set to font-size-x-large.

I'm curious to know your thoughts on these issues. We should at least run them by the Web team to see if they think this is an acceptable experience until font modes are implemented in skins.

For components used within Vector which are not excluded from the text size preferences, and use @font-size-medium or @line-height-medium, we will see some unintended design details. This will be most prevalent where an element which uses one of these tokens is among other elements which use other font-size and line-height tokens that do not scale. What we will see are unintended, disproportionate typographic hierarchy and visual balance.

Some places where these issues will appear are where text is paired with an icon that is size small or x-small, such as in Button, Card, MenuItem, Message, Label, Select, TextInput (and anything which wraps TextInput), and TextArea. The most broken being the TextArea with icon in large mode. TextArea is unique because the line-height of the text is wider, and the icon is designed to remain aligned with the first line of text. Though, I'm a bit confused why the height of the icon is the correct height in small and medium modes, but completely wrong in large mode.

Another place we will see issues is in binary inputs, including Checkbox, Radio, and ToggleSwitch. This is because the switch in each is meant to scale with the text, but doesn't because it uses different tokens from medium to control its proportionate scaling. In Checkbox, the checkmark scales but the box around it does not. The most broken here being the ToggleSwitch in small and large mode. This is because there are very specific calculations being used to perfectly position the switch and grip.

Lastly, hierarchically, we will see issues where multiple text sizes are being used, and only medium is scaling. This includes Card, Dialog, Popover, and Table.

None of these issues are ideal. However, I would say that the ToggleSwitch one is the most important to address, as it appears broken, not just visually imbalanced. We have discussed making the values controlling the switch and grip position a component token, so that would theoretically fix this issue. I would also suggest we look into what's going on with the TextArea icon. This seems like a bug.

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

[mediawiki/core@master] Update Codex from v1.21.1 to v1.22.0

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

Test wiki created on Patch demo by Eric C Gardner using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/59d55f2723/w/

Change #1133258 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.21.1 to v1.22.0

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

Another issue I have found, which I do feel leans on the more problematic side, is that where @font-size-medium is used with @line-height-small, which is in most components. Now, the problem comes in where the text wraps to a second line, and specifically in large mode. This is because the font-size is scaling but the line-height is remaining the same.

In T386298#10705200, @DTorsani-WMF wrote:

Another issue I have found, which I do feel leans on the more problematic side, is that where @font-size-medium is used with @line-height-small, which is in most components. Now, the problem comes in where the text wraps to a second line, and specifically in large mode. This is because the font-size is scaling but the line-height is remaining the same.

First guts reaction: Would this be handled differently with unitless line-heights? 🤓 Or resulting in the same issue?
(there's no perfect pixel control in a dynamic environment, more generally there's no perfect control whatsoever in a dynamic environment, it should be seen as acceptable for such massive change to have edge cases(!) that are not perfectly covered)

Unitless line-heights would cause similar problems. @AnneT is going to talk with Web about this issue to see what they think and how we should resolve it for now.

@Jdrewniak @JScherer-WMF @bwang We've been testing the font modes work and have identified a few issues related to the fact that only the --font-size-medium and --line-height-medium CSS custom properties scale via the Vector 22 text size switcher, yet other font-size and line-height tokens are also used throughout Codex components. We've mitigated some of the issues but wanted to run a couple of larger ones by you all.

Note that these issues will be resolved once font modes are fully integrated into Vector 22 (meaning the text size switcher will scale all font-size and line-height tokens). These issues will temporarily appear between when we deploy Codex 2.0, which contains the font mode changes, and when we integrate them into the Vector 22 text switcher.

Let me know if you'd like to discuss any of this synchronously!

QuickSurveys

The QuickSurveys UI scales with text size, and there are a couple of issues when only the medium tokens scale:

1. For Checkboxes, the check mark scales but the box doesn't. At the large size, this means the check mark looks a bit too large for the box.
2. The icon-only dismiss button does not scale, so it looks small at the large size.

In the meantime, we could exclude QuickSurveys from scaling with text size to prevent these issues from appearing between when we release font modes in Codex and integrate them into the Vector 22 text size switcher. What do you think?

Messageboxes

Messages in the content pane also scale with the text size switcher. One issue we've found is that the text size scales, since it's set to @font-size-medium, but the line height does not as it's set to @line-height-small. Especially at the large text size, the line height is quite small:

Again, we could exclude messageboxes in the content section from scaling for now. Let me know what you'd like us to do here.

Integrating font modes into Vector 22

As mentioned, all of these issues will be resolved once we use the new font modes in Vector 22 to handle text size switching. I've created a proof of concept (patch, patchdemo) showing this. Obviously, there'd be more work to do - for example, we'd need to prevent the header and sidebars from scaling with text size, and we'd need to use Codex tokens for things like heading font-size (currently the page title does not scale). This is just to plant the seed that integrating font modes into Vector 22 will resolve this weird in-between state, and we'd like to discuss a path toward this goal at some point.

Content Translation

Testing in Special:ContentTranslation involved comparing component behavior with and without font modes, focusing on the default font size component styling rather than the scaling behavior.

Local testing environment:

• Make sure MediaWiki core, extensions, and skins are updated.
• Use these instructions to test the unmerged font modes changes in MediaWiki.
  • In Codex, check out to the main font modes branch: https://gerrit.wikimedia.org/r/c/design/codex/+/1123503
• Check out to this branch in Vector, which applies fixes to Less files: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1131031

Findings

• The dashboard includes Codex components such as CdxButton, CdxIcon, CdxSearchInput, CdxMessage, and CdxInfoChip.
• No Less compilation errors found.
• No appearance menu to switch font sizes in the user interface.
• CdxMessage - the close button’s alignment is no longer vertically centered with other header elements. Notice the alignment shift with the start icon and text in the attached before/after screenshots.

Before	After

Codex components in the dashboard are highlighted:

In T386298#10705845, @AnneT wrote:

@Jdrewniak @JScherer-WMF @bwang We've been testing the font modes work and have identified a few issues related to the fact that only the --font-size-medium and --line-height-medium CSS custom properties scale via the Vector 22 text size switcher, yet other font-size and line-height tokens are also used throughout Codex components. We've mitigated some of the issues but wanted to run a couple of larger ones by you all.

Note that these issues will be resolved once font modes are fully integrated into Vector 22 (meaning the text size switcher will scale all font-size and line-height tokens). These issues will temporarily appear between when we deploy Codex 2.0, which contains the font mode changes, and when we integrate them into the Vector 22 text switcher.

Let me know if you'd like to discuss any of this synchronously!

QuickSurveys

The QuickSurveys UI scales with text size, and there are a couple of issues when only the medium tokens scale:

1. For Checkboxes, the check mark scales but the box doesn't. At the large size, this means the check mark looks a bit too large for the box.
2. The icon-only dismiss button does not scale, so it looks small at the large size.

In the meantime, we could exclude QuickSurveys from scaling with text size to prevent these issues from appearing between when we release font modes in Codex and integrate them into the Vector 22 text size switcher. What do you think?

Messageboxes

Messages in the content pane also scale with the text size switcher. One issue we've found is that the text size scales, since it's set to @font-size-medium, but the line height does not as it's set to @line-height-small. Especially at the large text size, the line height is quite small:

Again, we could exclude messageboxes in the content section from scaling for now. Let me know what you'd like us to do here.

Integrating font modes into Vector 22

As mentioned, all of these issues will be resolved once we use the new font modes in Vector 22 to handle text size switching. I've created a proof of concept (patch, patchdemo) showing this. Obviously, there'd be more work to do - for example, we'd need to prevent the header and sidebars from scaling with text size, and we'd need to use Codex tokens for things like heading font-size (currently the page title does not scale). This is just to plant the seed that integrating font modes into Vector 22 will resolve this weird in-between state, and we'd like to discuss a path toward this goal at some point.

Thanks @AnneT for doing this testing! It makes sense to me to be safe and exclude problematic areas like messageboxes and quicksurveys.

so it sounds like the Web team should create a new task for integrating font modes into Vector 22? And that includes font size and line height for everything basically? do you have a sense of when this needs to be done by?

Thanks @bwang! I created T391890 to capture the work of excluding those UIs from scaling.

I went ahead and created T391891 to cover integrating font modes in Vector 22. This does include scaling all font-size, line-height, and size-icon tokens. There's no specific due date, but we'd like to at least start discussing this now so we can form a general plan for when we might tackle this. Please feel free to pose additional questions in either task!

@DTorsani-WMF / @Volker_E is the typography page part of this task done? I see that there is a typography page in the Sandbox but there's no font mode switcher.

@AnneT I'm actually unsure where @Volker_E ended up with the Sandbox type pages, so I will let him answer this one.

Test wiki on Patch demo by Eric C Gardner using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/59d55f2723/w/