Theme: Use adjusted Segoe font-face for medium -> semibold fallback - #80020
Theme: Use adjusted Segoe font-face for medium -> semibold fallback#80020aduth wants to merge 4 commits into
Conversation
aduth
added
[Type] Bug
github-actions
Bot
added
[Package] Components
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +2.36 kB (+0.03%) Total Size: 7.68 MB 📦 View Changed
|
There was a problem hiding this comment.
Thanks for the PR! I have confirmed that this approach works correctly in both Chrome and Firefox.
This approach works well under a pure design system, but may not be the case for WordPress sites.
In the post editor and site editor, this old font family provided by core is basically applied. Therefore, if we specify weight 500, it will refer to Segoe UI as before and fall back to 600.
Please refer to the screenshot below. Almost all bold text is falling back to 600, but Column Count and Row Count within the table placeholder will render at weight 500.
This means that because the application of the new font family is inconsistent, changing the weight to 500 will result in variations in the actual rendered thickness.
I believe that to solve this issue across WordPress, we would need to directly add font-face and font-family to the core common.css. However, I think it would be too risky to try this in the 7.1 release.
|
If the approach is promising but we don't want to merge it before 7.1, let's make sure that we leave If we're confident in this approach as-is, it looks fine, since the changes are only internal (ie only token values are being changed, no public API changes). This also means that the same a11y shortcomings mentioned before will continue to be around for now, but I guess a known shrotcoming is better than unknown bugs |
|
I see. So, what do you think of the following procedure?
I don't fully understand the design system yet, so please let me know if there's anything I'm getting wrong. |
|
@WordPress/gutenberg-components let's all take a moment to review the proposed approach. |
|
Given how widespread this impact is, I think we've transcended this being just a design system problem 😅 It seems that we're in a tricky spot where we want to use 400 and 500 as different weights to express hierarchy, and also want to use system fonts, but the Windows system font doesn't have a 500 font weight, and the spec behavior of fonts is such that without significant coercion (as implemented here), it will fallback to 400 and thus violate the desired hierarchy. As far as what that all means for how we proceed today:
|
Emphasis on this. If we want to move to |
|
I realized there is another factor that complicates this issue: since Segoe UI is a font designed for Western languages, different results can be obtained with other languages. For example, when Japanese was used, I obtained the following results in my environment. https://codepen.io/editor/Tetsuaki-Hamno/pen/019f4ae8-8594-743d-9cb9-f1ebcb227034 Chrome: Perhaps because Noto Sans JP has recently been included by default, the weight 500 is now rendering correctly. 
Firefox: In my environment, since Meiryo is applied, weight 500 falls back to 400. However, if Noto Sans JP is explicitly applied in the browser settings, weight 500 is rendered correctly, similar to Chrome. 
Even if we migrate from 500 to 600, there might be no guarantee that weight 600 can represent the intended weight across all operating systems, languages, and browsers. For example, as I mentioned earlier that Meiryo is applied as the system font in Firefox, it seems that the Meiryo font only supports weights 400 and 700. Therefore, weight 600 will fall back to 700. 
To put it extremely, using only weights of 400 and 700 would be the most stable method, but I don't think this is ideal. Perhaps it's reasonable to give up on solving all scenarios and just change the medium font weight from 499 to 500, leaving it to each OS, language, and browser to determine how that weight is actually rendered. |
That is true, but there's a fundamental difference between 500 and 600:
As inconvenient as either option is, in terms of accessibility and visual hierarchy, the 600 fallback feels like a better/safer behavior to me. It ensures minimal buttons / links are different from non-interactive text, and it makes headings stand out. |
I see. Then, would the best approach be to remove the medium token, create a new token for semibold, and replace the existing medium token with the semibold token? |
That's what I'm suspecting, too. I can also create a PR to test that approach |
|
Opened #80093 to test the medium -> semibold approach. |
|
Noting that I shared some relevant feedback here. |
|
Flaky tests detected in 6f3e03d. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29083848793
|
|
Closing as superseded by #80093. |
4 participants
What?
Closes #79525
Defines a custom Segoe UI font variant to control the fallback behavior for Windows system font missing medium font-weight (500), preferring to fall back to a bolder font (600) than a lighter font (400).
Why?
As described in #79525, our typography scale relies on visual distinctiveness between regular (400) and medium (500) font-weights. But currently, Windows browsers will show a 400 font-weight for everything, because the Segoe system font does not include a 500 font-weight.
How?
@wordpress/themeand@wordpress/base-styles, ahead ofsystem-ui@font-facedeclarations to define "Segoe UI WordPress Adjusted" to emulate the default behavior, with one exception:'Segoe UI Semibold'is registered atfont-weight: 500instead of the default effectivefont-weight: 600so that it is used at weights between 500 and 700 (default is that it is used between 600 and 700).There's a lot more discussion in #79525 to the technical considerations of this implementation, specifically around specification behavior and browser behavior inconsistencies.
Testing Instructions
Verify visual hierarchy of boldness in Storybook "Text" story, ideally from a Windows machine:
npm run storybook:devScreenshots or screencast
The screenshots below are captured in a Windows environment, which is what's most impacted by these changes:
Use of AI Tools
Implemented with assistance by Cursor + Claude Opus 4.8, with reviews and iterations prompted by myself.