Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix/button css specificity #12005
Reduces specificity in core button styles to ease clashes with theme styles.
This takes care of some cases mentioned here #11677
And attempts to solve #11998 by giving the Twenty-* themes 1 single button class selector to style
The button color was added to the parent
The CSS selectors for the Text Color and Background Color settings have been given more specificity to override
Duplication of the class selector is used here for two reasons:
How has this been tested?
In depth visual tests were done in browser.
Types of changes
Bug fix (non-breaking change which fixes an issue)
Thanks so much for this pull request. Really appreciate it
It's a little bit hard to follow the CSS changes — they seem good on the face of it, but I'd appreciate a sanity check and good testing across at least the vanilla style and twentynineteen, plus all variations.
Here's the vanilla style:
As you can see from the above, all looks good except for the twentynineteen variation preview.
However an initial
Thanks for checking this out @jasmussen!
Twenty Nineteen isn't great for testing this since it's not using the default color methods and options.
Also, while not specifically to blame for the results in your Button Preview screenshot, it's worth noting the influence that the mapped
Not sure I'd call the "duplicate selector for the purpose of specificity" a hack. It does behave the way it's supposed to according to the W3C https://www.w3.org/TR/selectors-3/#specificity
Though we probably could use a CSS comment here since this rule may be new to some.
I'm not aware of any performance issues with the
As for @chrisvanpatten's suggestion to use repeated classes for font sizes, I'd absolutely recommend that.
Might also be worth pulling these style from the
YESSSS this would be amazing. Having these classes separated out would be so cool.
I think this is more straightforward, and easier to parse, vs
I think this is a sensible path forward. I don't think it's necessarily the best scenario (that would be Gutenberg generating CSS for color palettes and font sizes so we can ensure correct specificity) but this is definitely a step in the right direction. I think anything we can do to simplify the CSS and reduce specificity to the bare minimum will make things easier for themers to override.
This seems to work as intended, and have a lot of thought put into it, plus sanity checks. I trust that it improves the situation, so let's keep moving. But do add a comment about the double-use of the selector as a CSS comment, something a la
// Double the class name to increase specificity ... something in that vein. Thanks!
On a glance, this wasn't obvious to me at all. Is it not also making a very fragile assumption about the specificity of the thing it is meant to override? Could it be enough to do
This is actually a common use of
I don't disagree @aduth. I think the case could be made for
It is making an assumption that what it's overriding will precede it and have no more than two classes or a class and a pseudo-class such as
Yes, but it makes an assumption that the hypothetical future maintainer is aware of these circumstances should they decide naively to add some specificity to the class selectors these are meant to override.
That's a possibility.
Would be awesome though if WP could right it's past transgressions and make single class selectors it's norm or even the rule.
I'm going to continue to help however I can to move us in that direction.
I'm not against