Font-size values (normal & huge) defined in theme.json conflict with default editor styles #59701

lunule · 2024-03-08T00:38:19Z

Description

If you're using font sizes in theme.json with the slugs normal and/or huge, the specified values get overwritten in the admin by default editor styles.

A setup in theme.json like this don't work in the admin:

{
	"version": 2,
	"settings": {
		"typography": {
			"fluid": true,
			"fontSizes": [
				{
					"fluid": {
						"min": ".888rem",
						"max": "1rem"
					},
					"name": "Normal",
					"size": "1rem",
					"slug": "normal"
				},
				{
					"fluid": {
						"min": "1.333rem",
						"max": "1.777rem"
					},
					"name": "Huge",
					"size": "3rem",
					"slug": "huge"
				}								
			]
		}
	}
}

... because the following default editor styles overwrite the correct settings:

.editor-styles-wrapper {
    --wp--preset--font-size--normal: 16px;
    --wp--preset--font-size--huge: 42px;
}

Step-by-step reproduction instructions

Set up a blank FSE theme
Define 2 custom font sizes in theme.json with the slugs normal and huge, with size values any other than the following:
- 16px for normal
- 42px for huge
Create a new page, and add some Lorem Ipsum text - then select a paragraph and change the font-size to huge.

You'll see that the font-size value applied doesn't match the values defined in theme.json.

Screenshots, screen recording, code snippet

No response

Environment info

WP 6.4.3 - Gutenberg plugin not active, blank theme
OS: Windows 11

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

The text was updated successfully, but these errors were encountered:

ramonjd · 2024-03-08T02:34:05Z

Thanks for filing this issue.

Has this bug been fixed already? 🤔

I tested in Gutenberg trunk, and also WordPress 6.5-beta3-57723-src without any plugins installed, and couldn't reproduce.

2024-03-08.10.29.00.mp4

lunule · 2024-03-08T06:22:13Z

Hey @ramonjd , thanks for your quick reply.

In your video, I think you're using block styles.
The reported issue is different, it's about the font size values defined in the theme.json file's typography > fontSizes section.

The below gif displays how these font sizes get displayed in the editor sidebar.

The main issue here, as far as I see, is that this overwrite breaks the fluid typography feature enabled in the theme.json file as well.

I used a hotfix in the editor stylesheet, overwriting the style pushed by the default editor style with the font size values used in theme.json, but

this seems going against the DRY principle
fluid typo is still broken by these editor stylesheet styles for the two font sizes (normal and huge).

The hotfix looks like this:

.editor-styles-wrapper,
:root {
    --wp--preset--font-size--normal: 1rem;
    --wp--preset--font-size--huge: 1.777rem;

    @media ( max-width: 768px ) {
	    --wp--preset--font-size--normal: .888rem;
	    --wp--preset--font-size--huge: 1.333rem;    	
    }

    @media ( min-width: 1601px ) {
	    --wp--preset--font-size--normal: 1rem;
	    --wp--preset--font-size--huge: 1.7777rem;     	
    }    
}

A permanent fix would be providing a way to disable specific default editor styles, like the one reported here.

ramonjd · 2024-03-09T01:34:26Z

In your video, I think you're using block styles.
The reported issue is different, it's about the font size values defined in the theme.json file's typography > fontSizes section.

Oh sorry, I forgot to mention I was using the theme.json font size presets mentioned in this issue's description, and was just applying those sizes at the block level yes.

May I ask, have you tried testing in WordPress 6.5 beta or with the latest Gutenberg version? I only ask because the issue cites

WP 6.4.3 - Gutenberg plugin not active, blank theme

But there was a pretty major bug fix that was merged since 6.4, that might be related:

Font size: Allow for custom font size handling #58422

lunule · 2024-03-09T23:38:31Z

Hey @ramonjd ,

Thanks - I'm totally overwhelmed with a theme project now, but I'll reply as soon as I have some spare time, on 18th Monday at the latest.

carolinan · 2024-03-11T06:47:16Z

I can confirm that this has been fixed in 6.5. The font size in theme.json is used, even when it matches an existing CSS variable.

Normal and huge are legacy font sizes that used to be part of the default preset, but were renamed. They are output in the editor and front for backward compatibility.

ramonjd · 2024-03-12T21:17:35Z

Thanks for confirming @carolinan

I'll close this issue as fixed.

@lunule if you can still reproduce in WordPress 6.5 or with the latest Gutenberg version, please feel free to reopen. 👍🏻

iamtakashi · 2024-03-28T16:24:29Z

Possible regression. The huge size went back to 42px for me in the editor with Gutenberg trunk. The size is correct on the front of the site.

t-hamano · 2024-03-29T15:35:07Z

I was also able to reproduce this problem with the latest Gutenberg.

I used the theme.json below and tested it in the site editor.

theme.json

{
	"version": 2,
	"settings": {
		"typography": {
			"fluid": true,
			"fontSizes": [
				{
					"fluid": {
						"min": ".888rem",
						"max": "1rem"
					},
					"name": "Normal",
					"size": "1rem",
					"slug": "normal"
				},
				{
					"fluid": {
						"min": "1.333rem",
						"max": "1.777rem"
					},
					"name": "Huge",
					"size": "3rem",
					"slug": "huge"
				}
			]
		}
	}
}

WP6.5 RC4

The body element outputs the correct user-defined CSS variables. At the same time, a CSS variable with the default font size is output via the selector :where(.editor-styles-wrapper), but this does not cause any problems as it is overridden.

Latest Gutenberg

In the latest version of Gutenberg, this style relationship is reversed.

ramonjd · 2024-04-02T00:47:17Z

It's because of this change:

Global styles: output :root selector for CSS custom properties #42084

Specifically https://github.com/WordPress/gutenberg/pull/42084/files#diff-b03597cc3da199e5aa5a94950e8241135904853e7c3b82d758e42744878afae7R46

I'm not sure what to do here.

The :where(.editor-styles-wrapper) rules are defaults that persist for backwards compatibility.

gutenberg/packages/block-library/src/editor.scss

Line 69 in ae90414

:where(.editor-styles-wrapper) {

But they conflict with a progressive change, that is, using :root for CSS custom properties.

Also, block-library is a curious place for these styles. Not so curious when we see that they were added in 2021 (Gutenberg 12.2/WordPress 5.9)

Since Gutenberg only supports the last 2 versions of WordPress, should we consider deleting these styles as a solution to this issue?

t-hamano · 2024-04-02T02:09:01Z

Since Gutenberg only supports the last 2 versions of WordPress, should we consider deleting these styles as a solution to this issue?

I think these styles are meant to support older WordPress versions that don't use Gutenberg, so I'm concerned that these styles can't be removed.

However, on the editor side, these styles seem to exist in duplicate:

packages/block-library/src/common.scss: :root selector is used
packages/block-library/src/editor.scss: :where(.editor-styles-wrapper) selector is used

I'm not that knowledgeable, but I think it might be possible to delete these styles defined in editor.scss 🤔

A similar issue has been reported in #56293, but @oandregal mentions this issue in detail in this comment, so maybe he knows something about it 🙏

lunule · 2024-04-02T23:36:59Z

@ramonjd

The :where(.editor-styles-wrapper) rules are defaults that persist for backwards compatibility.

In this case, wouldn't it be a workable strategy to inject these rules in a version-dependent way, e.g. for versions below v6.4 or similar?

Even better, it would be great if

developers had a filter or an add_support rule to use to enable/disable these forced styles in the theme's functions.php file, or
a similar "switch" to use in the theme.json file

... where, as we're talking about a feature that exists solely for backwards compatibility, the default state of the "switch" would be off (rules not added to any of the predefined stylesheets) - then theme authors developing with backwards compatibility in mind could simply enable the feature.

(Basically, my main main concern with this issue is the forced nature of the inclusion of CSS presets with preset names that'll most probably be used by theme authors in the development process.)

ramonjd · 2024-04-03T01:12:08Z

(Basically, my main main concern with this issue is the forced nature of the inclusion of CSS presets with preset names that'll most probably be used by theme authors in the development process.)

I agree, this is regrettable, but I think I might have found a couple of workable alternatives:

We move .editor-styles-wrapper to the HTML tag in the iframe component. :root has higher specificity therefore any theme CSS properties underneath will take precedence.
We insert the backwards compat CSS into the iframe via JS before any :root rules are output.

I've tested number 1, as the second seems inherently sketchy:

Editor styles: relocate .editor-styles-wrapper class to the HTML element #60398

ramonjd · 2024-04-03T01:20:00Z

In this case, wouldn't it be a workable strategy to inject these rules in a version-dependent way, e.g. for versions below v6.4 or similar?

Its a good question. I'm not sure.

Backwards compatibility is an important consideration for any WordPress change, but there's no one way of maintaining (and breaking) it.

It's probably a naive idea, but I think it would be nice to put all backwards compat fixes in a little box, e.g., a hook to allow folks to disable some or all of them completely on their sites.

Nevertheless, there are other, less technical paths, such as education and communication:

Should be constrained as much as possible to a small surface area of the API.

Should be documented as clearly as possible to third-party developers using Dev Notes.

https://developer.wordpress.org/block-editor/contributors/code/backward-compatibility/

It's hard to judge when backwards compatibility is no longer possible or sustainable. Maybe in a few years we'll come back to this issue and decide 2028 is the time to delete the styles 😆

ramonjd · 2024-04-03T01:57:22Z

I've tested number 1, as the second seems inherently sketchy:

Number 1 broke too many things.

The sketchy one seems to work and has a lighter footprint:

Editor styles: delete duplicate backwards compat CSS custom properties #60400

t-hamano · 2024-04-13T04:22:48Z

I looked into this issue by looking at what priority CSS variables have in each WordPress version. This problem occurred in WP6.4 and was resolved once in WP6.5. However, the issue has been reproduced in the latest Gutenberg.

The following shows how a CSS variable with a slug of huge is overridden if the font size is registered via theme.json.

WP6.3.4

✅ Non-iframed Post Editor

/* Inline style */
.editor-styles-wrapper {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
.editor-styles-wrapper {
    --wp--preset--font-size--huge: 42px;
}
body {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
:root {
    --wp--preset--font-size--huge: 42px;
}

✅ Iframed Post Editor and Site Editor

/* Inline style */
.editor-styles-wrapper {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
/* editor.min.css */
.editor-styles-wrapper {
    --wp--preset--font-size--huge: 42px;
}
/* style.min.css */
:root {
    --wp--preset--font-size--huge: 42px;
}

WP6.4.4

✅ Non-iframed Post Editor

/* Inline style */
.editor-styles-wrapper {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
.editor-styles-wrapper {
    --wp--preset--font-size--huge: 42px;
}
body {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
:root {
    --wp--preset--font-size--huge: 42px;
}

❌ Iframed Post Editor and Site Editor

/* editor.min.css */
.editor-styles-wrapper {
    --wp--preset--font-size--huge: 42px;
}
/* Inline style */
body {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
/* style.min.css */
:root {
    --wp--preset--font-size--huge: 42px;
}

WP6.5.2

✅ Non-iframed Post Editor

/* Inline style */
.editor-styles-wrapper {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
:where(.editor-styles-wrapper) {
    --wp--preset--font-size--huge: 42px;
}
body {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
:root {
    --wp--preset--font-size--huge: 42px;
}

✅ Iframed Post Editor and Site Editor

/* Inline style */
body {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
/* editor.min.css */
:where(.editor-styles-wrapper) {
    --wp--preset--font-size--huge: 42px;
}
/* style.min.css */
:root {
    --wp--preset--font-size--huge: 42px;
}

Latest Gutenberg plugin

❌ Iframed Post Editor and Site Editor

/* editor.css */
:where(.editor-styles-wrapper) {
    --wp--preset--font-size--huge: 42px;
}
/* Inline style */
:root {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
/* style.css */
:root {
    --wp--preset--font-size--huge: 42px;
}

✅ Non-iframed Post Editor

/* Inline style */
.editor-styles-wrapper {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
/* editor.css */
:where(.editor-styles-wrapper) {
    --wp--preset--font-size--huge: 42px;
}
:root {
    --wp--preset--font-size--huge: clamp(2rem, 2rem +((1vw - 0.48rem)* 1.923), 3rem);
}
/* style.css */
:root {
    --wp--preset--font-size--huge: 42px;
}

It's difficult to find out the root cause due to the complicated history, but editor(.min).css appears to be causing the problem in both WP6.4 and the latest Gutenberg. Additionally, style(.min).css with the same CSS variables is also loaded in the editor in all versions, so it appears that editor(.min).css can be safely deleted.

I would like to test if #60400 solves this problem.

ramonjd · 2024-04-15T04:29:40Z

Fixed by #60400

lunule added the [Type] Bug An existing feature does not function as intended label Mar 8, 2024

lunule changed the title ~~Font-size values (normal #) defined in theme.json conflict with default editor styles~~ Font-size values (normal & huge) defined in theme.json conflict with default editor styles Mar 8, 2024

jordesign added the [Feature] Typography Font and typography-related issues and PRs label Mar 11, 2024

t-hamano mentioned this issue Mar 12, 2024

Font size "huge" does not respect the size specified in theme.json #54918

Closed

ramonjd closed this as completed Mar 12, 2024

t-hamano reopened this Mar 29, 2024

ramonjd mentioned this issue Apr 3, 2024

Editor styles: relocate .editor-styles-wrapper class to the HTML element #60398

Closed

ramonjd mentioned this issue Apr 3, 2024

Editor styles: delete duplicate backwards compat CSS custom properties #60400

Merged

ramonjd closed this as completed Apr 15, 2024

t-hamano mentioned this issue Apr 15, 2024

New CSS properties (WP 6.4) in editor.min.css are overwriting font sizes from theme.json #56293

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Font-size values (normal & huge) defined in theme.json conflict with default editor styles #59701

Font-size values (normal & huge) defined in theme.json conflict with default editor styles #59701

lunule commented Mar 8, 2024

ramonjd commented Mar 8, 2024

lunule commented Mar 8, 2024 •

edited

ramonjd commented Mar 9, 2024

lunule commented Mar 9, 2024

carolinan commented Mar 11, 2024

ramonjd commented Mar 12, 2024

iamtakashi commented Mar 28, 2024

t-hamano commented Mar 29, 2024

ramonjd commented Apr 2, 2024

t-hamano commented Apr 2, 2024

lunule commented Apr 2, 2024

ramonjd commented Apr 3, 2024

ramonjd commented Apr 3, 2024

ramonjd commented Apr 3, 2024 •

edited

t-hamano commented Apr 13, 2024

ramonjd commented Apr 15, 2024

Font-size values (normal & huge) defined in theme.json conflict with default editor styles #59701

Font-size values (normal & huge) defined in theme.json conflict with default editor styles #59701

Comments

lunule commented Mar 8, 2024

Description

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

Please confirm that you have searched existing issues in the repo.

Please confirm that you have tested with all plugins deactivated except Gutenberg.

ramonjd commented Mar 8, 2024

lunule commented Mar 8, 2024 • edited

ramonjd commented Mar 9, 2024

lunule commented Mar 9, 2024

carolinan commented Mar 11, 2024

ramonjd commented Mar 12, 2024

iamtakashi commented Mar 28, 2024

t-hamano commented Mar 29, 2024

WP6.5 RC4

Latest Gutenberg

ramonjd commented Apr 2, 2024

t-hamano commented Apr 2, 2024

lunule commented Apr 2, 2024

ramonjd commented Apr 3, 2024

ramonjd commented Apr 3, 2024

ramonjd commented Apr 3, 2024 • edited

t-hamano commented Apr 13, 2024

WP6.3.4

✅ Non-iframed Post Editor

✅ Iframed Post Editor and Site Editor

WP6.4.4

✅ Non-iframed Post Editor

❌ Iframed Post Editor and Site Editor

WP6.5.2

✅ Non-iframed Post Editor

✅ Iframed Post Editor and Site Editor

Latest Gutenberg plugin

❌ Iframed Post Editor and Site Editor

✅ Non-iframed Post Editor

ramonjd commented Apr 15, 2024

lunule commented Mar 8, 2024 •

edited

ramonjd commented Apr 3, 2024 •

edited