Core block styles are overriding theme.json styles in WordPress 6.6

[ndiego]

Description

If you have applied styles to specific elements in theme.json, perhaps blocks as well, there is a chance that they will be overridden by default block styles. I have not had a chance to test this issue widely, but I discovered (with the help of @bgardner) that the element styles in theme.json for Image block captions are no longer respected in 6.6.

Take a look at the screenshots below. You will see that the specificity changes in #61638 seem to have swapped the style order. This causes the block style to override theme.json. In my opinion, theme.json should always "beat" default block styles.

Step-by-step reproduction instructions

1. Use the Twenty Twenty-Four theme and WordPress 6.6 Beta 3+
2. Add an image with a caption to the page
3. In theme.json, add the following to the caption element

"spacing": {
	"margin": {
		"top": "10px",
		"bottom": "0"
	}
}

4. View the image on the front end and see that the block styles override for margin override those set in the theme.json

Screenshots, screen recording, code snippet

WordPress 6.5	WordPress 6.6

Environment info

• WordPress 6.6 Beta 3+
• Gutenberg 18.5

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

[ndiego]

cc @ellatrix @aaronrobertshaw 🙏

[bgardner]

I can concur this is happening, as the example @ndiego used came from work I was doing earlier today. I have experienced other similar cases of core block styles overriding theme.json as well, so it's not limited to what he mentioned above.

[bgardner]

Another example of this can be seen with css styles I have applied to Post Comments Form block in theme.json (https://github.com/bgardner/powder/blob/main/theme.json#L369) which now require the use of !important to ensure the border-color is being applied properly. For the sake of demo, here's a screenshot with the override happening after I have omitted the !Important in the inspector. The textarea should be #0a0a0a (contrast color) but it's now #949494.

[mtias]

Adding priority high—these issues can erode confidence in using the toolset around block themes, so should do our outmost to address them preemptively.

Where are we with regard to absorbing all cosmetic block styles in the bundled theme.json file that ships with WordPress?

[ellatrix]

It's false that this was introduced by #61638, which merely increased the specificity of theme.json styles from 0 to 0-1-0, to fix most issues with reset and default styles. This was introduced by #60106, which reduced all theme.json styles to 0-0-0. You can test this yourself by checking the previous commit. The default style specificity was then lowered for image/theme.scss, but not image/style.scss.

[bgardner]

@ellatrix and others... so what about instances of css in theme.json? While #62689 fixes the caption issue that @ndiego reported, it does not seem to address two instances of css that I tested (one of them being reported in #62679 (comment)).

My two instances were:

https://github.com/bgardner/powder/blob/main/theme.json#L512
https://github.com/bgardner/powder/blob/main/theme.json#L512

Screenshots of these styles getting overridden still by core using Playground with the PR:

[ndiego]

Any bugs aside. Is it correct to say that styles defined in theme.json should always "beat" default block styles?

[ellatrix]

Any bugs aside. Is it correct to say that styles defined in theme.json should always "beat" default block styles?

Yes, normally they should. But there were reasons for setting the specificity of theme.json to the same level. I think @aaronrobertshaw or @tellthemachines can explain better.

Maybe there's a way to mass-reduce all default styles to specificity 0-1-0. I'm not sure. And there might be other consequences.

[ellatrix]

@bgardner Aside from the comment textarea, are there more instances? I can fix them in a PR.

[bgardner]

@ellatrix Yes, the social icons css is also not working (https://github.com/bgardner/powder/blob/main/theme.json#L512) and second screenshot in this comment (#62679 (comment)).

[bgardner]

@ellatrix Any chance the PR gets into RC 1 tomorrow?

[ellatrix]

I created a PR for the textarea. I don't know what is causing the social links issue, more information would be helpful.

[talldan]

@bgardner I made a PR for social icons - #63049, does that resolve the issue you're seeing? I imagine there may well be other issues, but assumed the colors were the most important to fix.

[bgardner]

@talldan Yes, using Playground, I just tested to see if the removal of !Important leaves the social icons styled as expected.

Confirmed, and works! Possible we get this into RC2?

[jhmonroe]

Any bugs aside. Is it correct to say that styles defined in theme.json should always "beat" default block styles?

Yes, normally they should. But there were reasons for setting the specificity of theme.json to the same level. I think @aaronrobertshaw or @tellthemachines can explain better.

Maybe there's a way to mass-reduce all default styles to specificity 0-1-0. I'm not sure. And there might be other consequences.

Here's a great roundup of the 0,1,0 story and related links at bottom for anyone who is struggling and finds this issue/discussion: https://make.wordpress.org/core/2024/06/21/wordpress-6-6-css-specificity/