CSS Specificity for WordPress 6.6

[aaronrobertshaw]

Background

As implementation of the section styling feature for WP 6.6 has progressed, one of its key use cases, nested section styles, has presented an interesting challenge. Nested section styles require uniform or “level” specificity in style selectors so the style load order can be leveraged.

Initially, this was seen as an opportunity to completely lower our core style specificity to 0-0-0, making overriding these styles predictable and trivial for theme authors. The reduction to zero-specificity has already commenced within Gutenberg but does come with some caveats.

This discussion is to propose an alternative to zero-specificity and document a decision on a path forward for WP6.6.

Goals

1. Make overriding core styles easier and more predictable
2. Unlock section styling via nested block style variations which require level specificity

Why not CSS layers?

There's currently no easy way to enforce all styles to be contained within a layer. Any "unlayered" styles take precedence over all "layered" styles. This scenario is much like core styles being set to zero-specificity but 3rd party stylesheets accidentally overriding them.

There is a current proposal aimed at adding support for a layer attribute to HTML <link> tags. Once implemented, that would open the door for functions like wp_enqueue_style etc. to support specification or enforcement of layers.

It's important to note that while CSS layers might not be viable soon, there is nothing stopping either of the options detailed below from being stepping stones to leveraging CSS layers in the future. When that time comes, a shift to zero-specificity within any given layer becomes much easier.

Available Options

Option 1 - Zero Specificity using :where(...)

Historically, there have been several requests to lower the specificity for core styles. A few going as far as suggesting these styles should have zero specificity. The main desire here was to make overriding core styles as easy as possible.

Core styles have been reduced to zero specificity in Gutenberg already, primarily via the following PRs.

• Try reducing specificity of global styles block selector. #57841
• Reduce specificity of global styles body margin reset rule. #61340
• Try reducing specificity of layout style selectors #60228
• Try reducing specificity of global styles selectors only. #60106
• Reduce specificity of block library styles conflicting with block supports #59457
• Make sure to replace all instances of :where(body) instead of just … #61602
• Reset specificity of body selector when processing with postcss. #60266

This reduction to zero specificity has caused a few regressions such as Global Styles failing to take effect on some blocks, common reset styles bleeding into block styles etc. Some fixes have landed while others are still open.

Issues reflecting these regressions include:

• Styles missing with custom fields panel active #61565
• Reduce specificity of block library styles conflicting with block supports #59457 (comment)
• Plugin 18.3.0 disabled theme customizations #61582
• Global styles are overridden by theme's CSS #61533
• Separator Block: Border styles set in theme.json are overwritten by the Gutenberg plugin #60634
• Pullquote: Theme defined padding is overridden by default #60646
• Block Styles: Reduce specificity of block style variation selectors #61032 (comment)

Related issues from external repos:

• Navigation: Gutenberg 18.1 reduced specificity breaks link text-decoration
• Discrepancy in Font Family between editor and frontend
• Assembler color styles are not applied properly in Safari

The above lists are not comprehensive however they do illustrate some of the downside if we stick with zero-specificity styles, or switch to another approach, when early adopters may have already been through the process of adjusting their styles.

The majority of the zero-specificity changes have been in the Gutenberg plugin since 18.1, early in the WP 6.6 release cycle.

WordPress commits to maintaining backward compatibility, so the breakage to global styles and requiring themes to update selectors for common reset styles or their custom blocks goes against this commitment.

The upside of zero-specificity for core styles is that it fulfills broader requests from the community, namely, that CSS specificity is lowered as much as possible to make it trivial to override any core style.

It's entirely possible the community might decide the minor style issues and updates are worth the benefits and flexibility gained from zero-specificity styles.

Pros:

• Maximizes customization ease
• Ideal specificity for core styles if designing style system from scratch
• Fulfills some community requests for zero-specificity styles
• Already implemented within Gutenberg

Cons:

• Higher potential for breaking theme and global styles
• Requires theme authors to update their block and reset styles
• Needs substantial communication and documentation to help ensure smooth adoption

Option 2 - Reduce Specificity to 0-1-0 using :root :where(...)

This option revolves around reducing our core style specificity using :where() but prefixing it with :root . The result is selectors with 0-1-0 specificity.

An in-progress PR implementing this approach is also available.

This is a compromise between reducing specificity all the way to zero and maintaining backward compatibility.

It achieves the following:

• Prevents common reset styles from bleeding into block styles (e.g. ul,ol { margin: 0 } overriding default and global styles for the social links block)
• Avoids requiring theme authors to update selectors in their resets or custom block styles for the vast majority of cases
• Unlocks section styling so that block style variations can be applied in a nested fashion
• Provides a predictable low specificity for core block styles that should still be relatively easy to override
• A step towards a future implementation leveraging CSS layers (once there is a broadly supported method for enforcing all styles are contained in a layer)

It is still possible that this approach may require a tweak or two to some more complex blocks' styles however any blocks that use the default class selectors, e.g. .wp-block-*, should remain largely unaffected.

As nice as zero-specificity styles across the board would be. Recent testing and explorations have highlighted an increased potential for breaking themes, global styles etc.

Pros:

• More robust than zero-specificity styles
• Preserves existing resets
• Does not require theme updates for the vast majority of block styles
• Global reduction in specificity although not to zero
• Predictable low specificity for easier overrides to core styles
• Not all prior work and effort towards zero specificity is lost

Cons:

• Does not reduce specificity as far as Option 1
• The purpose of the :root prefix is not immediately obvious and requires documentation

Questions

• Do you foresee any additional challenges or benefits with either approach?
• How do you propose addressing potential issues raised with each option, such as the impact on theme resets and overrides?

I’d love to hear any thoughts from @WordPress/gutenberg-core & @WordPress/block-themers to unblock section styling in time for WP6.6.

[aaronrobertshaw]

I believe the latter approach (Option 2) using the :root prefix is our most robust path forward as it:

• honors as much as possible our commitment to backward compatibility
• unlocks new features such as section styling
• still makes overriding core styles easier and more predictable
• provides a path forward to a CSS layers and zero-specificity future

[richtabor]

I agree. Do we have an understanding of the risk of styles not resolving properly?

What's the best way to get this moving forward for potential addition to WordPress 6.6? I think we should get this in to give ample time for 6.6 beta testers to test.

[aaronrobertshaw]

Do we have an understanding of the risk of styles not resolving properly?

That's a great question @richtabor! It's also a bit of a tricky one to answer 😅

We do have a fairly solid understanding of the risks with Option 2. They are much clearer and more limited than Option 1.

The catch is that the potential edge cases are rather contrived so it's been difficult to get a gauge with concrete numbers via searches of WP Directory etc. The searches to date have not turned up more than a couple of themes or plugins that might be candidates for such edge cases.

To me, this is a good sign that the current preferred approach (Option 2), is fairly solid. That said, I'll try and give some example use cases illustrating the risk posed below.

Custom Blocks With Complex CSS Selector

Take a use case where we have a custom block that meets the following conditions:

• Uses a complex selector with specificity greater than 0-1-0 as the block's primary selector
• Opts into global styles e.g. margins, typography etc
• Enqueues a default stylesheet for the block
• Within its default stylesheet the block defines styles using the complex selector that would conflict with global styles (note the styles must target the block wrapper to conflict)

If our global styles specificity is reduced to 0-1-0 via Option 2, this block would need its stylesheet updated to wrap the complex selector in :root :where(...) so that global styles could be applied again.

Note: If we preceded with Option 1 instead, any block adopting global styles but setting defaults for those styles in the block stylesheet, would require updating their stylesheet selectors.

The best starting points for identifying plugins that might be affected are those that define complex CSS sectors for a block using either __experimentalSelector or the selectors API within their block.json files.

• Using __experimentalSelector
• Using selectors

The most notable there is WooCommerce however I couldn't find any plugins or themes that targeted its complex block selector. So it doesn't appear to be an issue.

Of the plugins using the selectors API, only 3 out of that list might be impacted however again I couldn't find any references to those selectors in other plugins or themes that would overlap with global styles.

Block Style Variations

Currently, our exposure here is rather limited as only core block style variations can be customized via global styles. This will change though with #57908.

Once #57908 lands and custom blocks and their style variations are configurable via global styles, those blocks may need to tweak their stylesheets to leverage the new feature. For example, if a custom block defined default margin styles for their variation using a selector such as .wp-block-custom.is-style-fancy, it would need to reduce that by wrapping it in :root :where(...) so the global styles could take precedence.

Another risk here is a block theme that overrides global styles configurable styles for a block style variation via a standalone stylesheet rather than through theme.json. An example of this could be:

• Theme enqueues a stylesheet overriding padding or border for the Button block's Outline style
• Theme uses the .wp-block-button.is-style-outline selector to target Outline buttons and apply padding/border
• User attempts to tweak the button block's padding and border within global styles

With Option 2, the global styles specificity would be lower and wouldn't take effect.

This is where I found it difficult to judge our exposure through searching WP Directory. A naive search simply for the .wp-block-button.is-style-outline selector, returns mostly false positives as those results would need to cull any classic themes, block themes where global styles were disabled for properties that might conflict with the theme's styles etc.

What's the best way to get this moving forward for potential addition to WordPress 6.6? I think we should get this in to give ample time for 6.6 beta testers to test.

This is where I think our time in the lead up to, and during, the beta is best spent 👍

The best way to help move this all forward will be to test and review #61638. That's the PR that implements Option 2. It also has a few nice little fixes, such as allowing blocks which set default padding once a background color is applied to also work with global styles.

#61638 should be ready to merge within the next couple of days, ahead of the last Gutenberg RC before the 6.6 beta. While that happens, I'll also be updating the section styling PR and ensuring it works well with the 0-1-0 specificity. Extra eyes there would be very beneficial as well.

---

Hopefully, that wall of text was enough to communicate our risk exposure here. If it doesn't, please let me know 🙏

[fabiankaegy]

Thank you for this write up. It certainly isn't an easy or straightforward decision.

One of the main issues I keep running into when using block specific Stylesheets that are loaded via wp_enqueue_block_style is that when they get inlined the global styles inline CSS gets loaded later in the document. So even when they have the same 0.1.0 specificity the custom Stylesheet is not able to override the core default styles without modifying the specificity of the block selector which comes with other maintenance issues.

I have just gone through the exercise of running 6 very different client projects through testing with the Gutenberg Plugin Version 18.3 activated to see whether I could find any regressions. The only one that came up in two small cases was not related to the lowered specificity, but instead the change of where custom properties are defined (the fact that they are now on :root instead of body (which I'm very happy about)). The sites I tested ranged from hybrid themes that were built about 2 years ago to block based themes in development now.

Based on my testing at least I would be in favor of option 1 because the long term benefits of this approach outweigh the downsides for me.

[fabiankaegy]

I think, fundamentally, there might be some nuance missing from how we think about the "layers" of our styling system.

Today we have something like this:

• block stylesheets
• global styles inline CSS
• theme styles

To me there is more nuance than that. Something more like this would more accurately represent what's happening:

• core theme.json output (wp_theme_json_data_default)
• block stylesheets (default styles of a block)
• blocks theme.json output (wp_theme_json_data_blocks)
• theme stylesheet
• theme block specific stylesheets
• theme theme.json output (wp_theme_json_data_theme)
• user theme.json output (wp_theme_json_data_user)

(The names of the theme.json layers are coming from: https://make.wordpress.org/core/2022/10/10/filters-for-theme-json-data/)

The issue today is that for example the core button comes with default styles that are defined in the core theme.json file located here:

gutenberg/lib/theme.json

Lines 336 to 358 in 0f68078

	"button": {
	"color": {
	"text": "#fff",
	"background": "#32373c"
	},
	"spacing": {
	"padding": {
	"top": "calc(0.667em + 2px)",
	"right": "calc(1.333em + 2px)",
	"bottom": "calc(0.667em + 2px)",
	"left": "calc(1.333em + 2px)"
	}
	},
	"typography": {
	"fontSize": "inherit",
	"fontFamily": "inherit",
	"lineHeight": "inherit",
	"textDecoration": "none"
	},
	"border": {
	"width": "0"
	}
	},

These core styles cannot be overwritten by a theme without doing odd specificity hacks because they are getting output in the global-styles-inline-css inline style tag which loads after all the rest of the stylesheets.

Running Gutenberg 18.3 fixes all these issues today because the zero specificity essentially produces this hierarchy through specificity:

• global styles inline CSS
• block stylesheets
• theme styles

A quick search of WP Directory shows a pretty high potential for themes to use reset stylesheets that will bleed into block styles if we choose to proceed with zero-specificity.

Okay, looking at the examples here I can see an issue for global styles that are defined by the user or the theme in theme.json that they now have a lower specificity than any CSS that targets the same element. This isn't great I can agree with that. To me it comes down to the issue outlined above. I think there should be a difference in specificity between theme / user level theme.json generated styles and WordPress core default styles.

What are your thoughts on Option 2 and how we could avoid most of Option 1's downsides? Long term, we can still safely move towards zero-specificity once CSS Layers can be enforced.

From my point of view, even the change to a standardized enforced 0.1.0 specificity has the potential of breaking things. It also changes the way that core styles behave in relation to custom code. So if we are making a change I would still say it should rather be a change that actually solves a lot of the issues the community has asked for for a long time, than breaking things whilst not really getting noticeable benefits from it (for the extenders).

If we are not comfortable

[aaronrobertshaw]

It's quite possible I'm missing something around the layers of our styling system. It would be great to get some clarification from @tellthemachines given their experience in this area.

To me there is more nuance than that. Something more like this would more accurately represent what's happening:

Were you listing here what you think is happening or should be happening?

It's worth noting the filters for different theme.json origins don't create different layers or stylesheets. So the global styles stylesheet (or stylesheets if separate block assets enabled) don't work as that list would appear to suggest.

With WordPress/wordpress-develop#6010 & #58761 the style load order became:

• Block library styles
• Base global styles (element styles, etc)
• Block-specific global styles

This order should be the same regardless of whether should_load_separate_core_block_assets is true or false.

There was a fair bit of discussion that went into that order so I believe it to be pretty solid.

The issue today is that for example the core button comes with default styles that are defined in the core theme.json file located here:
...
These core styles cannot be overwritten by a theme without doing odd specificity hacks

This might be where we're on different pages 🙂

I don't think a block's stylesheet should be looking to override the global styles or theme.json styles. They set defaults or styles for themes without global styles.

Wouldn't a block theme wishing to override the core button element styles, do so in its own theme.json? If the theme only wanted to override the button element for a specific block type, it could do that within its theme.json defined styles for that block type.

For example:

{
	"styles": {
		"blocks": {
			"my-block": {
				"elements": {
				 	"button": {
				 		"color": { ... },
				 		"spacing": { ... },
				 		"typography": { ... },
				 		"border": { ... },
				 	}
				 }
			}
		}
	}
}

Running Gutenberg 18.3 fixes all these issues today because the zero specificity essentially produces this hierarchy through specificity:

That could be an unintended side-effect of the zero-specificity change when themes don't update their block library styles as expected. It was expected that custom block stylesheets would also reduce their specificity to 0-0-0 so that global styles could still work if they adopted them.

Block library styles that didn't get reduced to zero-specificity were actually what caused most of the regressions noted under Option 1.

To me it comes down to the issue outlined above. I think there should be a difference in specificity between theme / user level theme.json generated styles and WordPress core default styles.

This would be a significant change in the way theme.json and global styles work. Definitely not something for WP6.6 😅

Given the issue you outlined could be addressed (if I understood it correctly) by overriding styles within the theme's theme.json, does that mean for WP6.6 you'd be ok with Option 2 now?

I'd like to stress there is nothing preventing more of an overhaul to the style system in the future. A possible shift to CSS layers would be the perfect time for it.

From my point of view, even the change to a standardized enforced 0.1.0 specificity has the potential of breaking things.

Agreed, however much less than a shift to zero-specificity. Especially when considering that any block relying on the default block class e.g. .wp-block-image wouldn't need to change anything to prevent either global styles breaking or bleed in from resets etc.

So if we are making a change I would still say it should rather be a change that actually solves a lot of the issues the community has asked for for a long time, than breaking things whilst not really getting noticeable benefits from it (for the extenders).

The community has asked for reduced specificity which either option provides to varying degrees. The community has also expressed frustration at updates breaking themes. Option 1 carries much greater risk than Option 2 in this regard.

If we are not comfortable

It looks like the end of your comment was cut off, if you have a chance I'd still like to hear the rest of your thoughts.

Thanks again for the time spent on this topic and the detailed comment 🙇

[cbirdsong]

Wouldn't a block theme wishing to override the core button element styles, do so in its own theme.json? If the theme only wanted to override the button element for a specific block type, it could do that within its theme.json defined styles for that block type.

They may want to override it in a way that can't be expressed in theme.json, like each subsequent button block alternating between a few colors using :nth-child().

[aaronrobertshaw]

Thanks for providing that use case @cbirdsong 👍

I wonder if it might be possible to add more pseudo selectors (e.g. :nth-child, :first-child etc.) for elements in theme.json to address that one.

[cbirdsong]

I imagine that would be good, but I really don't think that the CSS-in-JSON solution will ever be able to cover everything that CSS can do, so the idea that someone might not be able to do that should always be kept in mind.

[ellatrix]

Only a limited reduction in specificity

Why is that a con? What's the benefit of reducing it all the way to 0-0-0?

The purpose of the :root prefix is not immediately obvious and requires documentation

I'd say we'll anyway need documentation for :where as well, and additionally regarding resets etc.

Requires reverting some aspects of the recent zero-specificity work

Reverting is a big word. It does not really require reverting anything, I just added :root. I've changed some block library styles back to their original specificity, but that's not required.

Early adopters using Gutenberg >=18.1 might have already updated override styles to use zero specificity

Could you give an example? How can they add override styles?

[aaronrobertshaw]

Thanks @ellatrix, I've tweaked some of the wording and pros vs cons 👍

Why is that a con? What's the benefit of reducing it all the way to 0-0-0?

This was more a con relative to the zero-specificity option.

My understanding is that there was a general desire to lower specificity of core styles as low as possible, which would imply 0-0-0. If writing the style system from scratch, I suspect this is the specificity that would be used.

I'd say we'll anyway need documentation for :where as well, and additionally regarding resets etc.

This is true which is why I noted under Option 1's cons the following: "Needs substantial communication and documentation to help ensure smooth adoption"

Reverting is a big word. It does not really require reverting anything, I just added :root.

Fair point, I've tweaked this wording for others coming to the discussion later. I was thinking that we had started reducing specificity, now some of that was being undone to a degree.

Could you give an example? How can they add override styles?

Thanks for challenging that one!

After revisiting it, I think it was more that early adopters might have already reduced their styles unnecessarily. If they were being reduced such that global styles still took precedence, they shouldn't need changing if global styles specificity is bumped via a :root prefix.

Apologies for the confusion.

[talldan]

I definitely have concerns about the potential breakage that might happen with the zero specificity styles, it might just a small subset of styles, but even then to ship knowing there's an issue with resets seems risky. The stability of the public part of a user's site is to me the most important thing to uphold.

Maybe resets are an outdated way of doing things, but the reality is that WordPress can't just disregard all those existing themes. If there are ways to mitigate any breakage, it should be considered IMO, even if it's not the perfect system.

The discovery about zero specificity styles not working with resets not working also makes me wonder if zero specificity really is the ideal system. It seems to me that themes should probably be able to define styles that our both lower and higher specificity for total flexibility, so is a consistent specificity level instead the most important thing?

[peterwilsoncc]

I'm concerned about considering such a change in WordPress 6.6 as it places the front end of sites at significant risks. Such a change would need to be committed to WordPress-Develop early in the release cycle. As Beta 1 is two weeks away, it seems too late to consider this for 6.6. It's a really short release cycle this time around.

Dan's summed up my concerns nicely in the comment above so I won't rehash them. While effects in the site-editor are unfortunate, breaking the front-end of a large number of sites appears likely and is a bigger issue.

Reviewing the theme directory link Aaron provided, it seems that normalize.css is more common than a full reset but I suspect the effect of introducing zero specificity would be much the same.

[aaronrobertshaw]

Appreciate the feedback 👍

@peterwilsoncc, to clarify, is your concern more for Option 1 (zero specificity)?

Option 2 keeps specificity mostly the same across the board except for some of our more complex selectors for layout styles and block style variations. Do you see this option as possible for WP6.6?

[peterwilsoncc]

@aaronrobertshaw Mainly about option 1 to zero out specificity. Option 2 still seems quite risky to put in to WordPress-Develop late in the release cycle and best left for early-6.7.My experience, most recently with the Font Library, is that features get a lot more testing once they hit WP-Dev, especially for items used only in the site-editor.

[aaronrobertshaw]

Thanks for clarifying 👍

FWIW most styles were reduced to zero specificity in Gutenberg a few releases ago hence discovering more edge cases and regressions recently. The backports for those Gutenberg PRs though haven't yet landed in core.

Option 2 restores most of the original specificity and isn't a big change from the previous WP release. I'm pretty confident we could iron out any kinks that come up during the beta period.

[fabiankaegy]

@peterwilsoncc where do you see the difference between the CSS changes having been committed to WordPress core trunk vs. having been committed into the Gutenberg repository early in a release cycle.

As far as I understand things having something released in the Gutenberg plugin is much more beneficial because the number of sites testing it is much larger 🤔

And in this case a lot of the changes in specificity were committed at the very beginning of the 6.6 cycle. This discussion here is only happening because of that because whilst testing there were concerns found which lead to now taking a slightly different approach 🤔

[youknowriad]

Thanks for this deep discussion and the alternative proposals above. It seems to me, that Option 1 has a higher potential of a breaking changes and we probably don't have enough time before 6.6 in order to be able to judge the impact of the changes properly.

Now looking at the cons of Option 2:

Does not reduce specificity as far as Option 1

For me, that's not really a con. Reducing specificity to "0-1-0" or "zero" for core styles is kind of a random choice. The important thing is that everyone (core developers, themers, plugin authors) are aware of the level of specificity core uses and that it's "hopefully" consistent as much as we can. Also, If I'm reading things properly, 6.5 might not use the exact same selectors but the level of specificity there is almost equivalent.

The purpose of the :root prefix is not immediately obvious and requires documentation

Yes, but so is the purpose of :where to me to reduce specificity to 0 for resets. So both share the same con here. Also it seems based on @ellatrix's comment above, plugin authors and core blocks can even keep their pre-existing CSS (no root prefix) and still work as intended.

---

For me, it seems that the second approach at this point is clearly a winner here in order to be able to move forward with the section styling feature. (Almost no breaking changes, and some light changes to core styles).

In the future, it's clear that CSS layers are exactly what we need here. Hopefully, we can try to see how to introduce them iteratively for the future (maybe when the possibility to assign a layer to style elements is added)

[DaniGuardiola]

May I suggest a temporary "polyfill" that would unlock CSS Cascade Layers today?

Not familiar with the PHP code involved, but I suspect the temporary solution could look something like this (simplified pseudo-code):

function wp_enqueue_style {
-    echo style
+    echo "@layer name {" . style . "}"
}

I actually did something similar for a past project (part of a PostCSS plugin). Worked quite well. Ref: https://github.com/Create-Inc/archetype/tree/main/packages/archetype/scope#layering

Code is quite simple too: https://github.com/Create-Inc/archetype/blob/main/packages/archetype/src/postcss-scope-plugin/utils/apply-layer.ts

[DaniGuardiola]

Did you mean @import when talking about sequential load, or am I missing something about the layer at-rule?

[aaronrobertshaw]

🤦 Yes, sorry, I did mean @import.

[DaniGuardiola]

I'd like to understand this more.

I'm not sure it would work in all situations and for our style system to use CSS layers, every style would have to be in a layer.

Can you elaborate why this wouldn't be possible with my approach? Any specific examples that come to mind?

While not as "nice", this approach would be functionally equivalent to the <link> proposal AFAIK.

CSS Layers will become an option but they aren't really at the moment

Why is that? I know that the <link> proposal would be helpful, but I'm not sure it's blocking, e.g. my workaround might do the trick cleanly. So I'm wondering if I am missing something else.

I'm raising this point precisely because it seems like this issue is, in a way, about looking at alternatives to what would be preferred (CSS Cascade Layers), so I'm just trying to discern what is blocking the preferred option in the first place, and brainstorming a solution :)

[aaronrobertshaw]

Can you elaborate why this wouldn't be possible with my approach? Any specific examples that come to mind?

My understanding of wp_enqueue_style and the underlying WP_Styles class is that they support enqueuing stylesheets via URI, including external resources. These are done via the <link> element, which is then also filterable too.

Maybe I'm missing something with your suggested approach but I don't see how it would help in those cases. Would we not need to leverage @import to retrieve the external stylesheet to wrap in @layer? Perhaps it could be fetched and cached or something but again these a more complicated solutions that would need proper thought.

This thought, discussion, and exploration can definitely happen but as noted earlier that is best moved to a dedicated issue and not a candidate for 6.6.

[DaniGuardiola]

I am working on a PoC that would support these cases. No problem with the timeline, I'm not in a rush! Will share more when I have something functional. Thanks for your continued feedback :)

[luminuu]

I feel that Option 1 in the given timeframe of the 6.6 release is a no-go, considering the potential breaking of many sites if shipped with 6.6.

But even with Option 2 I'm not sure if this should be shipped with 6.6 immediately, but I'd prefer this over Option 1.

Both options need good documentation, which should not only be "we did that, do it this way" but also explain the technical aspects of using :root :where().

I think what also should be documented at some point is what @fabiankaegy wrote in this comment about the nuanced layers of styles that we have. I don't always find it super clear from where which styles are coming and I'm pretty sure many developers, who not have a close eye on core development, struggle with this too.

[wolffe]

How can one opt out of these styles?

WordPress 6.6 broke hundreds of our agency's websites, by underlining all links and by left aligning all centred images. All these changes are done via highly-specific :root and :where selectors.

They do not belong in core, they belong in themes:

:root :where(a:where(:not(.wp-element-button))) {
    text-decoration: underline;
}

:root :where(a:where(:not(.wp-block-navigation))) {
    text-decoration: underline;
}

Why are these in core?!

[cbirdsong]

You should file a new issue for this so it's not buried in this discussion.

[aaronrobertshaw]

To close the loop here, an issue was already created and has some discussion on the question posed here, see #63345 (comment)

A fix has been merged in Gutenberg and there is a core patch awaiting the 6.6.1 point release.