Reduce specificity of block library styles conflicting with block supports #59457
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tellthemachines
added
[Type] Enhancement
tellthemachines
requested review from
cbirdsong,
carolinan,
andrewserong,
fabiankaegy and
aaronrobertshaw
tellthemachines
requested review from
artemiomorales,
michalczaplinski and
ajitbohra
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: +155 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Thanks for splitting this out from #57841 👍
It is mostly testing well for me, in particular, in the editor.
When using a theme adopting wp-block-styles support and it comes to the frontend though I'm still seeing selectors that aren't wrapped in a :where() leading to a few visual inconsistencies.
From what I can tell it appears these styles might be from stylesheets included by core but take that with a grain of salt as I'm not well versed in how these block library stylesheets are handled.
| Audio | Embed |
|---|---|
 |
 |
|
Here's a few lines of code that might be handy for testing this PR - run it in the console and it inserts all the block examples into a post: var blockExamples = wp.data.select( 'core/blocks' ).getBlockTypes().filter( ( { example } ) => example ).map( ( { name, example: { attributes, innerBlocks } } ) => ( { name, attributes, innerBlocks } ) );
var createExamples = ( examples ) => examples.map( ( { name, attributes, innerBlocks } ) => wp.blocks.createBlock( name, attributes, createExamples( innerBlocks ?? [] ) ) );
wp.data.dispatch( 'core/block-editor' ).insertBlocks( createExamples( blockExamples ) ); |
Oh interesting, it looks like the theme styles from gutenberg are being included in the |
|
Update: I have a fix in #60098. |
aaronrobertshaw
approved these changes
Mar 22, 2024
There was a problem hiding this comment.
After cherry-picking the fix from #60098 to this branch locally, everything is testing well for me.
- Primarily tested with 2024, 2023, 2021, and 2020.
- In each theme, checked with and without
add_theme_support('wp-block-styles') - Global styles were still correctly applied to each of the affected blocks
LGTM 🚢
|
@tellthemachines About the button outline bug that exists in 6.5. I think you mentioned that there will be further specificity changes that will fix the issue in 6.6. Do you know which PRs do this and in which case we can consider the "Backport to WP minor" label to include these in a patch WP release? |
|
@youknowriad #60106 will fix that issue because it reduces the specificity of the element styles that are currently overriding the Button styles in the non-iframed editor. It reduces specificity for global styles selectors across the board though; not sure if that change is small enough to be a good candidate for a minor release. Another option that would also fix the bug is #56649, which is a much smaller change. I found some issues in testing it though, so it might need some further work. |
tellthemachines
added
the
Needs Dev Note
carstingaxion
pushed a commit
to carstingaxion/gutenberg
that referenced
this pull request
Mar 27, 2024
…ports. (WordPress#59457) Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org> Co-authored-by: talldan <talldanwp@git.wordpress.org>
ellatrix
reviewed
May 14, 2024
| @@ -2,6 +2,6 @@ | |||
| @include caption-style-theme(); | |||
| } | |||
|
|
|||
| .wp-block-image { | |||
| :where(.wp-block-image) { | |||
There was a problem hiding this comment.
This caused a regression: there's a default block style that is now being applied to the image block:
aaronrobertshaw
pushed a commit
that referenced
this pull request
May 17, 2024
aaronrobertshaw
pushed a commit
that referenced
this pull request
May 22, 2024
aaronrobertshaw
pushed a commit
that referenced
this pull request
May 24, 2024
aaronrobertshaw
pushed a commit
that referenced
this pull request
May 26, 2024
49 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Starts breaking down #57841 into its component parts.
This PR only addresses block-library styles, reducing specificity of rules that might conflict with global styles added to those blocks.
Testing Instructions
This can be tested on classic and block themes, but particular attention should be given to those that add support for
wp-block-styles(that's what enqueues thetheme.cssfiles from each block).Check that the blocks with style changes in this PR still display as expected. Global styles should work as well in this branch as they do on trunk, because their specificity hasn't been changed in this PR.