Size Change: +76 B (0%)

Total Size: 2.2 MB

_{compressed-size-action}

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: karmatosed <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

In general I support this change for the reasons outlined in #64744. But there are a few knock-on effects to consider:

Inspector

For me this is okay, with the exception of the Content panel. The text in the rows there should probably remain at their current wait to maintain visual consistency with the List view panel.

Text buttons in toolbars

This also seems okay. In fact on my screen the text weight feels more aligned with the icon weight which feels like a small win.

Inserter buttons

I don't have a strong feeling on this one so will defer to others. But like the toolbar, on my screen the text and icons feel a bit more cohesive.

ItemGroup

No strong feelings on this one either.

DropdownMenu

This one feels quite clunky. Should probably remain at the original weight to maintain alignment with Menu.

It would be nice if we could take into account that the default font may vary from OS to OS and that font weight 500 may not be supported. If the weight is not found, the fallback weight is applied.

In Gutenberg, the following font families apply:

-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif

On Windows, Segoe UI is applied, but this font does not support weight 500, so it is rendered as weight 600 (SemiBold):

Therefore, there is a larger visual change compared to Mac.

Before & After

Before

After

Even more confusing are non-Latin languages: Segoe UI doesn't support Japanese, so a separate font is applied for Japanese. If a Japanese font supports weight 500, a button may have both weights 500 and 600:

If we change the default weight of the Button to 500, we may want to review the font-family definition to ensure that weight 500 applies across most devices, operating systems, and languages.

@t-hamano looking at the fallback weight rule, I'd expect a fallback of 400 when 500 is not available — which would make this change a lot safer.

Would you know why this is not the case? Maybe the browser is trying to interpolate? Or maybe setting the value to 499 would cause 400 to be closer than 600 as a fallback?

looking at the fallback weight rule, I'd expect a fallback of 400 when 500 is not available

I expected the same, but for some reason the 600 weight was applied.

maybe setting the value to 499 would cause 400 to be closer than 600 as a fallback?

It seems to work fine in my environment. If it's 499, then 400 is applied; if it's 500, then 600 is applied.

https://codepen.io/Tetsuaki-Hamno/pen/PwPNGMV

Awesome. I'll experiment with 499 as well and see if we can get more consistent behaviours across browsers / OSs / font-families

I pushed some updates:

• changed from 500 to 499 ;
• forced 400 weight following Jay's feedback (row panel buttons, menu items)

@WordPress/gutenberg-design , any other places where we should avoid the new medium font weight?

@t-hamano, is text rendering correctly on your machine, for all the font-families used?

cc @WordPress/gutenberg-components

Flaky tests detected in 4d795e4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18640941543
📝 Reported issues:

• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js

@t-hamano, is text rendering correctly on your machine, for all the font-families used?

Yes. On Windows OS, font-weight 400 is applied as a fallback as before, so there should be no visual changes.

I would defer to @jameskoster and @jasmussen here as they are close to the system and I want to ensure they give feedback around what should or shouldn't keep medium weight.

The main issue for me was that items in the original Menu component have heavier font-weight than items in the newer menu component. Ideally these are aligned, and both utilise the same weight we see on trunk.

I don't have strong feelings about any of the other items highlighted in my previous comment.

Additional changes made

Fully addressed DropdownMenu df44071

Before	After

Maintained weight in DatePicker (matches new DateCalendar components) a47b1fe

Before	After

Maintained weight in BlockQuickNavigationItem 6f52782, as requested

Before	After

Other affected components (in addition to the ones already listed)

DuotonePicker: I'm leaving these as is with the heavier weight, because we're leaving the ItemGroup buttons as is and they are similar.

Before	After

⚠️ One final decision to make

Before	After

Making <Button variant="link"> heavier means that there will be a weight difference between a standard <a href="#"> and a <Button variant="link" href="#">, which are basically the same thing. @jameskoster Any preferences here? I think it would be simplest for consumers if we maintained a 400 weight for link variant Buttons, regardless of their ultimate markup (button or anchor).

@t-hamano As a follow up, I'm wondering if we should just update $font-weight-medium to 499. What do you think?

I think it would be simplest for consumers if we maintained a 400 weight for link variant Buttons, regardless of their ultimate markup (button or anchor).

Agree! We might consider phasing out the link button variant, it's quite a misleading design imo.

As a follow up, I'm wondering if we should just update $font-weight-medium to 499. What do you think?

That's a good idea. Additionally, we might be able to replace the hardcoded weights with SCSS variables and add rules to Stylelint to disallow hardcoded values.

Yes. On Windows OS, font-weight 400 is applied as a fallback as before, so there should be no visual changes.

I tested it again on Storybook, and there should be no visual changes at all on Windows.

I tried to figure out why @t-hamano's Windows browser would use the 600 weight as the fallback when the spec says it should use 400. And found this Chrome bug. Very old, unfixed, and specific to Windows and the Segoe UI font:

https://issues.chromium.org/issues/40552893