-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global Styles: fix specificity conflict of blocks with single classes as selectors #29378
Conversation
Size Change: 0 B Total Size: 1.39 MB ℹ️ View Unchanged
|
8d5e904
to
4302800
Compare
I came here to open this issue, that I had noticed with the site title block. The PR solves the problem for me. I tested this in TT1 Blocks, which has a theme.json setting for the site title font size: |
4302800
to
4534066
Compare
Thanks for looking for issues/PRs before submitting your report, Carolina. |
This is because we want the source order specificity for presets to be higher than for block styles, to fix cases in which the block selector has the same specificity as the class. Ex: - an user attaches the .has-white-color class to a block of type "my block", whose selector is .wp-block-my-block. - the themes targets the color of "my block" as well, generating a rule with the .wp-block-my-block selector. The color applied to the block that was tweaked by the user will be the last in the source.
4534066
to
2d49b36
Compare
Going to merge this one as it is a dependency of #29382 and the two test failures are unrelated. |
This PR fixes a bug in which the source order of blocks whose CSS selector is a class overrides user styles for preset values.
How to reproduce
The expected result would be that the user colors were respected. Instead, what happens is that the theme's colors are applied.
What's the fix
Load the preset classes after the block styles, so the last rule wins.
Note that there's a different issue with block selectors whose selector specificity is higher than the selector of user-selected styles (a class). #29381