Block Styles: Reduce specificity of block style variation selectors #61032
Conversation
aaronrobertshaw
added
[Type] Enhancement
aaronrobertshaw
requested review from
tellthemachines and
ellatrix
as code owners
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -35 B (0%) Total Size: 1.74 MB
ℹ️ View Unchanged
|
|
The rounded style for the image block looks a little different in this PR compared to trunk. This PR: Trunk: In this PR, this style rule seems to be taking precedence: .wp-block-image .is-style-rounded img, .wp-block-image.is-style-circle-mask img, .wp-block-image.is-style-rounded img {
border-radius: 9999px;
}While in trunk it's this one: .wp-block-image.is-style-rounded img, .wp-block-image.is-style-rounded .wp-block-image__crop-area, .wp-block-image.is-style-rounded .components-placeholder {
border-radius: var(--wp--preset--spacing--20);
}I'm not sure why there are two different 'rounded' styles 🤔 |
|
Thanks for flagging that @talldan 👍
TwentyTwentyFour customizes the core image block's rounded style via theme.json. I'll need to drop the specificity of the style within the Image block's stylesheet. I mistakenly thought this had already been done in other recent specificity related PRs and so never brought that tweak into the primary section styling PR. Before the section styling work, only core blocks' style variations could be customized through theme.json or global styles. My thinking is that if a theme or custom block adopts the enhanced block style variations, they might need to tweak their selectors to ensure they play nice with the reduced specificity needed to nest variations. It might be possible to leave variation styles at the current specificity but I believe long term we'll be best served keeping it to the minimum from the start if possible. |
aaronrobertshaw
requested review from
artemiomorales and
michalczaplinski
as code owners
|
I've updated the Image block's rounded style variation but there are a few other core blocks that need further attention. I'll work through those and update again when this is ready for review again. |
Yeah I'm afraid there hasn't been a concerted effort to lower specificity of all block library styles that might conflict with global ones; we've been doing it piecemeal as we find conflicts. We should probably lower specificity on all styles related to margin, padding, color and typography on all blocks (except ones like Gallery that have custom layout logic). Are you thinking of doing all that as part of this PR, or would it be better handled separately? |
A dedicated sweep sounds like a good option to avoid discovering conflicts in bit by bit kind of way.
I'm a little torn on this. The best situation for the extended block style variations is the reduced specificity for their styles. This makes them dependent on this PR, so it would be great not to block it. On the other hand, we don't want to break anything. My current thinking/hope was that we could only update styles that impact block style variations as part of this PR's scope. That way we limit any breakage there but somewhat keep the block style variations stuff moving. In other words, not every margin, padding, color, and typography, style on core blocks will be in the scope of this PR. Only those that disrupt a block style variation for now. What do you think? |
That sounds good! We can do the rest later. Agree this PR shouldn't be blocked by that work. |
Quick UpdateWhile working through a few of the block style variation default styles enqueued by core blocks, some edge cases have arisen that may postpone being able to land this reduction in block style variation specificity. Button BlockThe button block's stylesheet adds a default style for the Outline style variation, making the background transparent. If this selector's specificity is reduced to zero that default transparent background is lost to any global styles for the Button block or button element as these block library styles are loaded before the global styles. To fix this, we'd need a means of moving the default background style for the outline style variation to after the main global styles and before the block style variation styles. Some options here might be to introduce a new type of stylesheet for blocks, similar to Social LinksThe social links block uses the One option is that we could add an "unstyled" variant to the button component that doesn't include any styling at all. Table and Separator blocksI'm still working through the default variation styles for the Table and Separator blocks so there may still be some additional edge cases to add to this list. |
aaronrobertshaw
force-pushed
the
update/block-style-variation-specificity
branch
from
bd5f422
to
e7496e1
Compare
|
I've worked through the block library's styles that touch on block style variations. It needs some further testing before it will be ready for a final review though. There have also been some inline comments added to stylesheets where the reduction of specificity doesn't make sense. I'm happy to revert these if people don't think they add value. At the least, while reviewing they should flag that the selectors in question have been considered. The blocks in the library containing block styles include:
The Social Links styles have been updated to be compatible with the zero specificity of global block style variations. This includes fixing a regression introduced by #60106. Important: Reducing the Social Links block's selectors to zero allows bleed from the List block's styles due to it's element based selector |
This should now be fixed with #56469 merged! |
Related:
Note: The changes in this PR are being split out from #57908 to make that more manageable
What?
Reduces the specificity of block style variation selectors.
This is a continuation of #57659 and the overall reduction of global styles specificity in #57841.
Why?
To nest extended block style variations, as proposed in #57908, we need to reduce the specificity of related selectors to
0-0-0. This allows the load order of styles to determine the final cascade.This enables the ability for a block style variation to define inner block type styles without preventing an inner block from applying its own desired block style variation.
What happens if specificity isn't reduced?
Imagine a group block style variation that adds a border to inner image blocks. In this case, we'd end up with a selector such as
.wp-block-group.is-style-bordered-images .wp-block-image imgand a specificity of0-3-1.If we wanted to apply a rounded non-bordered image block style variation to a single inner image block, it would get a selector like
.wp-block-image.is-style-rounded-without-border imgwith0-2-1specificity.The result is the outer variation's
imgstyles incorrectly take precedence.Alternatives
Explorations were made into tweaking style variation selectors with
:notclauses to try and exclude inner blocks that have variations applied. The results here were brittle, incredibly complex, and only really worked for one level of nesting, leading back to the approach proposed in this PR.Testing Instructions
npm run test:unit packages/block-editor/src/components/global-styles/test/use-global-styles-output.jsnpm run test:unit:php:base -- --filter WP_Theme_JSON_Gutenberg_Test