Note to self, need to push a fix for the Gallery block:

This rule is now winning:

Easy fix, but will let you all add some thoughts first.

For that reason, I included a targeted rule for ol and ul elements, to keep their specificity. It's not an inclusion I love, but it feels necessary as the change feels very common. What do you think?

Interesting use-case, potentially we could consider doing this PR for just "resets" for now maybe? I think there might be other cases where themes could inadvertantly override the default centering margins (like figure maybe)

Interesting use-case, potentially we could consider doing this PR for just "resets" for now maybe? I think there might be other cases where themes could inadvertantly override the default centering margins (like figure maybe)

Agreed, even if we don't land this for the classic styles, it seems a win to land it for the reset. That said, this PR does solve an issue with navigation block justification in classic themes, which isn't trivial to fix otherwise: if I increase the specificity in the navigation block, I break global styles.

Size Change: +54 B (0%)

Total Size: 1.08 MB

_{compressed-size-action}

🤔 What happens if we do this to the editor styles as well (the ones injected dynamically)?

Blowing my mind with that idea. Do you happen to recall where we rewrite body to editor-styles-wrapper ? Happy to give it a shot.

I wanted to also add the thought that we could make the changes suggested here to everything except the left/right auto margins. While that breaks the nav block issue I noted (I can look for other fixes), it would still let us lower the specificity of the top/bottom margin rules, which would be a nice win.

@jasmussen it happens here https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/utils/transform-styles/transforms/wrap.js

basically, the ideal there would be to wrap without altering the specificity, not sure that's possible though

I gave it a shot, but I think that lowers the wrong specificity:

So this margin rule from the theme:

Now it loses to the block style:

In other words, it does work as intended. But we need to apply this to everything we want to be overridden. So in the case of the left aligned gallery, I can add the where to the editor style and it'd work.

basically, the ideal there would be to wrap without altering the specificity, not sure that's possible though

We could potentially use :is here: https://css-tricks.com/almanac/selectors/i/is/#specificity-of-is — but I may be missing some nuance of what you're saying.

There is a new selector, called :where, which is able to provide default styles with lowered specificity.

TIL, that's pretty neat! ✨

Zooming out a bit, did we have specificity targets for different parts of the editor? Using a comma delimited notation (style, id, class, element) with resets we'd probably stick with might have scores from (0,0,0,X), while blocks might be aiming for something like (0,0,1,X) to (0,0,2,X)?

As a reminder for folks 👀 CSS specificity is mostly counting. And no matter the number of items in one category it can't beat the next one. Using a comma delimited notation, if I say had 15 element rules in a selector a single class selector would still beat it.

In Joen's example in #32659 (comment)

This would be (0,0,1,1)

vs (0,0,1,0) (with the :where pseudo selector).

Zooming out a bit, did we have specificity targets for different parts of the editor?

It's been adhoc so far, but it might be good to start thinking about this in a more systematic way, in part because we have this new :where tool to provide very soft defaults, but perhaps more importantly because for global styles to work, the specificity of block styles has to be as low as possible for any theme.json specified overrides to take hold.

Do you have any good suggestions on how to start systematizing that? Are there any principles we can extract in documentation? Any linters we can add?

Curious, though, how did you calculate the specificity of .editor-styles-wrapper :where([data-block])? I suspect your value is correct, but I wouldn't know how to parse that particularly gnarly selector into the three categories, and online calculators get it wrong, probably due to unawareness of the particular qualities of :where; this one gives me 0,3,0.

Curious, though, how did you calculate the specificity of .editor-styles-wrapper :where([data-block])?

Manually counting, checkout also https://www.w3.org/TR/selectors/#specificity.

From the spec :where and it's argument are always zero

The Specificity-adjustment pseudo-class, :where() [...] neither the :where() pseudo-class, nor any of its arguments, contribute to the specificity of the selector—its specificity is always zero.

So with that in mind .editor-styles-wrapper :where([data-block]) simplifies to (0,0,1,0). And we can see that figure.wp-block-gallery does indeed beat it, which makes sense since it has a specificity of (0,0,1,1).

Do you have any good suggestions on how to start systematizing that? Are there any principles we can extract in documentation? Any linters we can add?

So probably the hierarchy of styling will probably be something like:

Reset / Base Styles -> Block Styles -> [ Custom Theme / Editor Styles ] -> Global Styles -> Specific Block User Overrides

If we can provide consistent specificity targets at the first two layers, then it should be easier to provide guidelines for folks building themes, and the necessary overrides for anything above that. Note that we don't necessarily have to use strict specificity guidelines if we're sandboxing styling in other ways (say isolating rules via iframes and such).

Thank you as always for teaching me, I very much appreciate that.

Your hierarchy reminds me of #20331, which seems like healthy serendipity worth building on. The tricky bit is the theme, as it requires some care on part of the author to not mess up the global style user overrides. However as those same properties are provided by theme.json directly, hopefully that helps manage the complexity.

I've got two navigation block PRs that are blocked on this one landing first: #33021 and #32574. I'd really love a review of this one, and ideally a green check because all it really does it reduce specificity so it should be safe. Thanks.

Reset / Base Styles -> Block Styles -> [ Custom Theme / Editor Styles ] -> Global Styles -> Specific Block User Overrides

This hierarchy makes sense but let me clarify the difficulty a bit here. In the frontend, the equivalent hierarchy is:

Block Styles ->  Custom Theme -> Global Styles -> Specific Block User Overrides

So our goal is to match both hierarchies as closely as possible, there are thought two main differences:

1- in the editor we need a Reset / Base Styles, this reset styles is basically something like:

.editor-styles-wrapper p { all: revert; }

that's just an example, the important bit here is that we're trying to reset the styles of the base elements to the browser's defaults by overriding the WP-Admin common.css styles. But by doing so we increased the specificity of p which means this creates a potential issue with the styles that are loaded later "Block Styles" and "Theme Editor Styles".

2- To solve the issue above what we did (a long time ago) is to add .editor-styles-wrapper to all editor styles. Meaning a theme writing p { color: red } in its editor styles will result in the following being loaded:

.editor-styles-wrapper p { color: red; }

The problem remains though for Block Styles which we don't wrap in .editor-styles-wrapper yet. So we have two potential solutions:

1- Try to wrap all the styles that can affect blocks with .editor-styles-wrapper, the important remaining one for us is "Block Styles" (the block-library package stylesheets)

2- Make sure the "reset" and the editor styles don't affect the specificity of their rules when they wrap the CSS with. .editor-styles-wrapper which this PR is attempting (I think), I think we're not there yet though.

Thanks @youknowriad and @gwwar for the reviews. Before we go deeper on the path of a hierarchy, is this PR okay to land as an interim step?

Thank you for the review, your reviews are the best, and excellent catch with the onselect alignment. Here's trunk:

Here's this branch before rebase:

Here's the branch after rebase:

Two immediate take-aways: you were completely right about the onselect alignment thing. I actually had a separate fix for that in #32574, but that may no longer be necessary, since it's possible it was inadvertently fixed by #33088 (which intended to be a more general refactor).

The other take-away is the added margin and padding. This is a side-effect of the reduced specificity of these styles, you can see in this GIF how the added margin and padding rules are from TT1:

Those rules are rather old and were wrong even before this PR, I've trac'ed them here: https://core.trac.wordpress.org/ticket/53220

There might be a few other such issues caused by theme styles having previously being overridden by higher specificity, now winning out. But I still think it's worth it to land this PR and "de-escalate" the specificity wars.

Thanks again for the review, I'll ask for a sanity check again before I merge.

In general, I think this looks good. I found few minor issues that can be addressed in follow-up PRs.

Tested with two WP installations side by side, using Demo content + Navigation (horizontal) justified to the right.

Installations:

A. Gutenberg build with this branch
B. Gutenberg 11.0

Themes tested

• TT1
• TT1 Blocks
• 2020
• 2019

Minor issues I spotted on this branch

TT1 Blocks

• None

TT1

• The gallery with no alignment isn’t centered.

2020

• Quote with no alignment isn’t centered.
• Gallery with no alignment isn’t centered.

2019

• Lists are centered.

Screenshots

this branch	11.0

this branch	11.0

Thanks for looking. I have this feeling those are all issues best addressed in the theme itself, does that seem right to you? If so, I'd be happy to create tickets for those and/or look at patches. Or did you get a sense that this was fixable in the block editor, without raising specificity again?

I'm not sure. I think some should be fixed in Gutenberg and some in themes.

In the case of the Gallery with no alignment, margin: 0 is coming from block's editor.css - https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/gallery/editor.scss#L22.

2020 theme adds the margin: 0 rule for blockquote in the editor, but then blockquotes are correctly centered on the front-end.

Excellent catch on the gallery. It appears to not be a problem with block themes as the left/right auto margins are enforced as !important.

But it is indeed a problem in classic themes, as the margin: 0 rule now wins out:

While I still think lowering that specificity, and actually updating the rule of the Gallery block to not have such a blanket zero margin output, it does make me question whether it's actually a good idea to update those classic rules at all. We might want to do it for the reset styles only after all 🤔

Block themes will still benefit from the new lowered specificity of the reset style. What do you think? And thanks again for looking.

Though it is worth noting, that if we don't include the lowered specificity, then improvements from #33021, just as an example, can't benefit classic themes. This will likely expand more widely as more properties like margins and paddings are absorbed into global styles.

The Gallery block issue would most visible, so it might be good to fix that as a follow-up.

I think it would be easier to gather more feedback if we merged this PR.

I'm waffling on merging it, as I'm going on vacation next week, so I won't have time to follow up on this. So at this moment I'm leaning towards pausing this one until I get back.

I'm back from AFK and hope to land this soon. Since it also appears to improve a 2019 theme issue, it would be good to land soon. I've rebased to test that it's still valid, and will be investigating the gallery block issue and how that can be fixed, and then either push a fix to this branch, or have a followup ready.

Alright, after investigating a bit further, it appears that the issue, as so well reviewed by @Mamaduka in #32659 (comment), is primarily an issue in classic themes. Here's what happens in 2020 that causes the gallery to be left aligned. The theme outputs this rule:

This rule is common for themes, as the figure element is born with intrinsic margins, including left and right margins. But with the new lowered specificity for the left/right auto margins, the following rule that is intended to center the top level block now loses out in specificity:

So there are two things we can do here.

1. Restore specificity for those auto margins.

This would be a bit of a bummer as I recall those margins being frustrating when I mostly worked on classic themes. But it might be a pragmatic choice for backward compatibility. Block themes won't have to worry about them, at least. Keep something like this in classic.scss, in other words:

// Provide baseline auto margin for centering blocks.
// Specificity is kept at this level as many classic themes output
// rules like figure { margin: 0; } which would break centering.
.editor-styles-wrapper .wp-block {
	margin-left: auto;
	margin-right: auto;
}

2. Expand the list of blocks with specific auto margins.

This PR already had the following in place, to center lists:

// This needs specificity to override theme editor styles
// such as ol { margin-left: 0; }.
.editor-styles-wrapper ol.wp-block,
.editor-styles-wrapper ul.wp-block {
	margin-left: auto;
	margin-right: auto;
}

We could expand that definition to include the figure element, which fixes the 2020 issue and still keeps the generic .wp-block class low-specificity. Something like this:

// This needs specificity to override theme editor styles
// such as ol { margin-left: 0; }.
.editor-styles-wrapper figure.wp-block,
.editor-styles-wrapper ol.wp-block,
.editor-styles-wrapper ul.wp-block {
	margin-left: auto;
	margin-right: auto;
}

It fixes it for 2020:

The downside to that approach is that it very slightly increases the specificity of those margin rules for classic themes. 0,2,1 for .editor-styles-wrapper figure.wp-block compared to 0,2,0 for .editor-styles-wrapper .wp-block.

Personally I'm slightly in favor of option 2, because those margins are annoying. But it's not a strong preference, and I'd be happy to go the potentially more pragmatic route.

Before I push anything, I'd love your thoughts. Thanks.

2. Expand the list of blocks with specific auto margins.

Personally I think this is a mistake and should be removed from all blocks, it shouldn't be the responsibility of the block to define its margins but should be the responsibility of its container ideally. Of course there might be special cases to clear out margins... but margin auto is very specific to the "flow" layout.

Going forward with block themes, there won't be any auto margin applied. But given how legacy themes have assumed those auto margins for a while, would you be okay with option 1 then?

Yes, I think option 1 is better. These "classic" styles are not "reset" styles meaning It's not clear whether they should have less specificity or more than editor styles. So I think keeping that rule as is is a good approach.

Awesome. Things still work well here:

Alright, it's Monday and I'll be here for any followups. This one after recent iterations feels very safe to me, so I expect when I merge it in a moment it will be a non issue. Nevertheless, let's keep an eye out on theme styles in the editing canvas!