Quote block: new CSS in Gutenberg 12.9.0 adds specificity and breaks existing themes

[markhowellsmead]

Description

The specificity of the new rule in the code snippet below is now 0,3,0 instead of 0,2,0 as before. This breaks pre-existing theme CSS.

Step-by-step reproduction instructions

Review an element styled using theme CSS which uses the selector .wp-block-quote.is-style-large p.

See also #36135, #35840, #34047, #29705, #17511 and #39971 and #40159.

Screenshots, screen recording, code snippet

.wp-block-quote.is-style-large:not(.is-style-plain) p {
    font-size: 1.5em;
    font-style: italic;
    line-height: 1.6;
}

Environment info

No response

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

[oandregal]

It seems that specific style rule has been introduced at #37580 cc @carolinan @ntsekouras

[MaggieCabrera]

I think .wp-block-quote.is-style-large:where(:not(.is-style-plain)) p should fix this.

[markhowellsmead]

The :where selector isn’t supported in around 12% of current browsers.

[MaggieCabrera]

The :where selector isn’t supported in around 12% of current browsers.

According to https://caniuse.com/?search=%3Awhere and https://make.wordpress.org/core/handbook/best-practices/browser-support/ I think it's pretty safe for us to use it (and we've done so before)

[markhowellsmead]

I know that :where has been used before and my statistical reference was to “Can I Use”. This support table indicates that although we're on the way to being able to use :where, a huge number of users worldwide will encounter broken layouts because of its usage. Take the relaunch of wordpress.org for example, where the entire navigation broke because of support issues with :where, which presumably had to be re-coded without it.

[talldan]

@markhowellsmead There was a discussion about the browser support - #39621. This might be what's being referenced.

As mentioned there, if browser support for specific features is a concern, I think it should be discussed by the community to gain some consensus, and then perhaps some rules can be implemented.

[markhowellsmead]

If I understand correctly, the browser support targets at https://make.wordpress.org/core/handbook/best-practices/browser-support/ indicate which browsers are targeted for WordPress admin and the Block Editor. This is perfectly understandable. However, the rapid increase of rules being applied in the front end of the website - which in many cases can hardly be overridden (if at all) by theme CSS - the effect is to start breaking current websites to the point where they quickly become unusable.

[talldan]

I think it'd be good if interested parties could make it a discussion point on the core-editor weekly chat agenda.

I would do it on behalf of those individuals but I can't really attend those meetings due to timezone, and I also haven't seen or been involved in the implementation or much of the prior discussion.

Until something like that happens, these are just isolated comments in amongst a thousand others on github.

[carolinan]

I tried different ways to remove the is-style-large class name from the block if default or plain style is selected, but I was not able to figure it out.

• I tried to get the selected block style, for comparison, but was only able to get the list of the block's available block styles.
• I tried to use TokenList and remove the class name, but it wouldn't save correctly.

[jsit]

It seems to me the correct thing would be for is-style-large to be removed from the HTML when switching to "Plain"; but barring that, maybe to reduce specificity, some unset styles can be set on .is-style-plain? As shown in this commit: 8cfc83a

Also, should this label be changed to [Type] Bug since this breaks themes?

[markhowellsmead]

@talldan I've mentioned such problems in multiple Github issues (which I was encouraged to create), discussed the problems with (what seem to be) several key developers on Gutenberg, and in a discussion in the Slack weekly to which I was invited. If that isn't sufficient to get anyone to pay attention, then I can't see much point in contributing any further. Although the work being done by core developers — on a voluntary basis in some instances — is remarkable, the direction of core CSS is making it harder and harder to overcome core decisions; feedback to this effect is largely being ignored, so we don't really have much choice and will have to come up with alternatives ourselves. The fact that an active participation in Github issues until now can be dismissed as an invisible drop in the ocean is a disheartening confirmation of the pointlessness of contribution by anyone outside the core development team.

[markhowellsmead]

Is this problem not being addressed?