WP 5.9 New Font Sizes Rules – Best Way to Handle

Hey @kennyll. I highly recommend joining the discussion here on this exact topic: https://github.com/WordPress/gutenberg/issues/38252

Hi, thanks for pointing that out! I hadn’t seen that thread when searching yesterday. I can sometimes get a little cross-eyed trying to follow cross-references & alternate issues on a GitHub thread, but that is helpful. It appears to have no real resolution as of now, so I suppose I’ll just have to keep an eye on it.

I guess I now have to just make a decision on how best to tackle this, and other related issues, with the new WP 5.9 release in a way that won’t have to be undone if these issues get resolved in another way directly in core WP.

Is creating a theme.json file in a child theme pretty safe & ‘future-proof’, given that the parent theme (e.g, Astra) may do something similar that might conflict or render things unnecessary?!?

Do I overwrite the CSS rule custom properties (e.g., ‘–wp-preset-font-size-medium’) in my stylesheet, and will this stick around for the foreseeable future?!?

I’m just going through 1 particular site that was launched in last 6 months and updated to WP 5.9. Beyond the font-size issues that I had to hunt down & override, I also happened to notice color overlay opacities getting overridden/reset or something. If we don’t keep detailed screenshots before every update (time consuming), we can miss something that’s not super obvious. And to have to carefully look over all the styling of our sites when doing a WP update is also just very time-consuming in itself. Our clients aren’t going to pay for this. Ugh. Hard enough to keep on top of the parent theme author’s wackiness when there are updates…

Hi, I have a follow-up question here. I am following the conversation on GitHub to see if any resolution comes about, but that may be a while. In the meantime I’ve started creating a theme.json file for sites to get sizes back to what they should be.

QUESTION:
– Is there any way for the listing in the Typography > Size box to display the “name” value from theme.json instead of the “size” value?

I know it will show the name as a tooltip if someone is patient enough to hover & wait, but it would be nicer if an arbitrary name that I could choose would be used instead. I could always use the size value as the name if that’s what I thought would be most helpful, but would be nice to be able to determine what is shown.

Where this becomes a problem is if you are using anything but a pretty small numerical value for the size (like the default WP even pixel values). If you need to use longer units, as for relative sizes like ems, this can break the interface. For example, we have a site with a root font-size of 17px. If we want to get an even 15px font-size using ems, it would be ‘0.882352941176471em’. This completely breaks the interface rendering it unusable.

Also, seeing these random em values, even if shorter (e.g, ‘0.8125’) is going to be very confusing to the end client. They’re not going to do the math to figure out the value, and they shouldn’t have to even think about it anyway. They should just decide whether they want the type to be ‘Small’, ‘Medium’, ‘Large’, etc. The theme developer (like us) decides how large these values equate to in the theme.json file.

Thanks for any insight here!

I was also struggling with this backward compatibility problem with Theme Twentytwenty, I am using a child theme.

Instead of creating a theme.json, I overwrote my functions.php with my old values for font sizes to see them in the block editor “typography”:

    // Block Editor Font Sizes after WP Update to 5.9.3
    add_theme_support(
        'editor-font-sizes',
        array(
            array(
                'size'      => "0.842em",
                'slug'      => 'small'
            ),
            array(
                'size'      => "1em",
                'slug'      => 'medium'
            ),
            array(
                'size'      => "1.25em",
                'slug'      => 'large'
            ),
            array(
                'size'      => "1.5em",
                'slug'      => 'x-large'
            ),
        )
    );

And in my custom css I added:

body {
  --wp--preset--font-size--small: 0.842em;
  --wp--preset--font-size--medium: 1.1em;
  --wp--preset--font-size--large: 1.25em;
  --wp--preset--font-size--x-large: 1.6em;
}

for fixing the font size problems in frontend.

It seems to work though not tested yet thoroughly. Maybe useful for somebody with similar issues.

Maybe it would be nice to list the pros/cons of using a theme.json file vs using ‘add_theme_support’ method?!?

I know when I did pretty much the same thing shown via ‘add_theme_support’ function I did NOT have to also add the CSS variables to my style sheet. Those are corrected in the inline ‘global-styles-inline-css’ when anything in theme.json file is changed. So it handles back-end and front-end in one place.

But I don’t recall off top of my head other pros/cons to either method…