Do you plan to lower the Specificity of the CSS selector for the block to 0?

[ddryo]

Description

I have a question about future policy.

Previously, styles for blocks had high Specificity, so to override them, the CSS loaded in the theme was loaded later than "wp-block-library-css".

add_action( 'wp_enqueue_scripts', function() {
	// wp-block-library
	wp_enqueue_style( 'wp-block-library' );

	// styles of my theme
	wp_enqueue_style( 'theme-style', '.../style.css' );
} );

However, over the past few years, with each update, the selector has been adjusted.

Even in this 6.4 release, some code had the level of Specificity lowered from 0-2-0 to 0-0-0.

/* 6.3 */
.wp-block-preformatted.has-background {
    padding: 1.25em 2.375em;
}

/* 6.4 */
:where(.wp-block-preformatted.has-background) {
    padding: 1.25em 2.375em;
}

This made it lose out to the reset css in the theme.

/* reset css in theme */
* {
    padding: 0;
}

The p.has-background etc. still seemed to be intact, but do you plan to lower their Specificity level to 0 in the future as well?

If so, then you will need to make a major revision to the CSS loaded in your theme and plugins.

Step-by-step reproduction instructions

Sorry, just a question.

Screenshots, screen recording, code snippet

No response

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

[ddryo]

Furthermore, even if we load the theme's stylesheet first, a styles with Specificity of 0 will lose even to the Tag Selector style ( Specificity 0-0-1 ).

For example, the initial style of the <pre> tag.

pre{ padding: 1rem }

[ddryo]

If you reduce Selector Specificity to 0 in the future, you should consider these effects.

Also, if you go with that policy, I think you should adjust the Selector Specificity all at once instead of changing it little by little.

If you change it little by little, we will have to adjust the style loading on the theme side every time with each update.

Also, if you are planning to greatly adjust the Specificity like this, I think that introducing "Cascade layer"(@layer) is a better option.

#51128

[Mamaduka]

cc @WordPress/block-themers

[carolinan]

As far as I am aware there is no general plan for updating the CSS specificity.
CSS is updated as needed when issues are reported, for example conflicts with styles from block settings, new block settings being added, changes to the layout system, and so on. In other words, I am not aware of any plans for any refactoring, changes are made on case-by-case basis.

[cbirdsong]

This is a frequent issue with CSS changes in each release 😒

• Big styling / specifity problems with WP 6.0 #41760
• New WP 6.3 CSS is overriding theme styles and styles from other plugins #53468
• WP 6.3 CSS specificity change breaks Block Gap margin in themes #53717

[eric-michel]

Agree with @cbirdsong - we fight with CSS specificity pretty much every release and I have to retouch dozens of sites to alter selectors in our child themes because they become either too specific or not specific enough.

Some kind of strategy behind where block selectors will end up is sorely needed. The vast majority of sites build with the block editor are going to do some amount of styling customization.

[carolinan]

I am not disagreeing. I have to do the same and it is a pain. But I still think that it is more important that the block settings actually work, than to prevent that theme developers need to make changes. It is my opinion only and please consider that and don't hold that opinion against Gutenberg at large.
From my personal more limited experience, I have more issues to fix when I have had to work around an issue before the fix is added to Gutenberg; when Gutenberg is patched I have to go and remove my now conflicting CSS.
The information that is shared with plugin and theme developers and users need to improve, but how?

[carolinan]

Issues like "this very specific CSS in this preformatted block, in this version or PR broke this" is always going to be easier to solve than "everything with the specificity is wrong"

[dbushell]

The fact is that changing CSS specificity can/will be a breaking change for theme developers.

As others have pointed out it has happened all too often with recent WP/Gutenberg updates.

It doesn't seem to me that this is taken seriously enough to fix the root cause (inadequate CSS strategy). I appreciate the difficulty of the task but that's all the more reason to put a halt on CSS changes and figure it out before continuing.

[cbirdsong]

It doesn't seem to me that this is taken seriously enough to fix the root cause (inadequate CSS strategy). I appreciate the difficulty of the task but that's all the more reason to put a halt on CSS changes and figure it out before continuing.

This. I understand this is hard, but a coherent strategy for CSS would greatly reduce the amount of breaking changes. There appears to be no overall guide for how to deal with writing CSS that respects changes made in the editor while also maintaining backwards compatibility.

For instance, this issue could be easily addressed be restructuring the selector to check for the existence of a style attribute, which would allow custom padding values to be used while keeping the specificity at 0,2,0:

.wp-block-preformatted.has-background:where(:not([style*="padding"])) {
    // set default padding
}

(It would also be great if classes were used whenever possible to allow for these kind of selectors to be written more easily: #54033)

From my personal more limited experience, I have more issues to fix when I have had to work around an issue before the fix is added to Gutenberg; when Gutenberg is patched I have to go and remove my now conflicting CSS.
The information that is shared with plugin and theme developers and users need to improve, but how?

The problem with this is that theme developers are not accustomed to having to circle back to old projects they may not even be working on to fix basic front-end things like this. Looking at the PR for this change, the selector's specificity was only discussed in the context of the editor functionality, and no thought at all was given to how a change to that would affect themes. This is extremely frustrating.

The solution to this is to avoid making breaking changes unless absolutely necessary, and that requires a coherent strategy for CSS.

[eric-michel]

The problem with this is that theme developers are not accustomed to having to circle back to old projects they may not even be working on to fix basic front-end things like this. Looking at the PR for this change, the selector's specificity was only discussed in the context of the editor functionality, and no thought at all was given to how a change to that would affect themes. This is extremely frustrating.

Absolutely yes. I have had to pull down and alter sites made by my predecessor 4 years ago. In worst case examples, I've had to actually touch each offending block to make things right (although I think that's typically been the result of block markup changes and not CSS).

I think the best example I can provide of this lack of strategy is #49815. The decision was made to change the fluid typography min/max resolutions from 768px/1600px to 320px/settings.layout.wideSize. That's a huge difference in before/after, and resulted in significant differences in font sizes at some resolutions for existing sites.¹

Nobody responsible for merge approval saw that change and raised a flag regarding backwards compatibility for actual live sites built using this feature. This was not a PR that was needed to fix an issue with the editor, a bug in a block, or to allow for a new setting. What that says to me is that styling impact to live sites is simply not a consideration at all when merging PRs.

There are many checks on PRs for performance, security, code quality, etc. There really needs to be some kind of deliberate check for live site effect as well.

• Are there changes in this PR that will affect styling on existing site?
• If so, are they necessary or can they be refactored?
• If they necessary, what can be done to alleviate the issue that live site admins and developer will face?
• If they are necessary and cannot be alleviated, how can we make sure admins and developers are notified during upgrade that these changes have been made and should be carefully reviewed?

I love Gutenberg. It has changed so much of how we develop sites for the better. But in classic WP I never worried about how a core update was going to affect the frontend of my site. Now I worry about it every cycle. It's gotten to the point that I feel like I need to dedicate considerable time to scouring this github and frequently testing the Gutenberg plugin to make sure I'm on top of the possible issues my sites will face.

Footnotes

1. To be clear, I have no arguments against the actual change that 49815 made, just that it was implemented with no consideration for how the change will affect existing sites ↩

[carolinan]

Do you have a person in mind who would be able and willing to take on, prepare, present and follow up on such a strategy for CSS?

Would you like to be pinged in issues or PR's that concerns CSS?
Because I have some PRS that have just been closed or that are being worked on, where help and testing would be appreciated.
For example #56130

[ddryo]

I think we can avoid many problems by introducing cascade layers.

Theme developers are no longer at the mercy of Gutenberg's CSS changes, and the Gutenberg team can continue to focus solely on tweaking Gutenberg's CSS.

[creativecoder]

I think we can avoid many problems by introducing cascade layers.

That seems promising. At a glance, perhaps there could be cascade layers that correspond to theme.json layers, 'default', 'blocks', 'theme', and 'custom', with custom being the default, outside a layer declaration.

[cbirdsong]

Using cascade layers has been proposed/discussed in #51128. Short version: the way @layer is implemented in browsers makes it very difficult to use progressive enhancement to incrementally migrate over to using them, so using them would have to wait for browser support to reach a critical mass and/or come with a reasonable Javascript-driven fallback for sites that don't want to use them yet.

---

Do you have a person in mind who would be able and willing to take on, prepare, present and follow up on such a strategy for CSS?

I would love to help with this but I do not have very much time to devote to it. I'd be happy to contribute to building out guidelines, but I definitely couldn't commit to the following up?

[scruffian]

I have more issues to fix when I have had to work around an issue before the fix is added to Gutenberg; when Gutenberg is patched I have to go and remove my now conflicting CSS.

I think this speaks to some of what is going on here. Historically the CSS that has been added to Gutenberg has been haphazard without care being taken to consider the overlap between blocks and themes. This often lead to themes fixing issues with blocks in the theme itself rather, because they didn't have another option. As we resolve issues in blocks this often means that the CSS added to themes to fix these issues becomes obsolete.

I do empathise with some of the frustrations here. We are trying to build a system that will enable themes to have control over most parts of a site using theme.json rather than CSS. To achieve this we sometimes need to modify some of the old CSS to make it less specific, so that the global styles CSS is stronger. In some cases this does change the appearance of these blocks in some themes, which is unfortunate and painful for those impacted. The benefit is that in the future themes won't need to control these settings with CSS and can use theme.json instead. We should only do this when absolutely necessary.