Common CSS: avoid false-positive border-style on custom properties#77476
Conversation
The attribute selectors [style*="border-width"] and [style*="border-color"] match any inline style containing those substrings — including CSS custom properties like --my-border-width or --fir-list-border-color. This forces border-style: solid on elements that have no actual border set. Replace each [style*="prop"] with a group of three selectors: [style^="prop"] — prop is the first declaration [style*=";prop"] — prop follows a semicolon (no space) [style*="; prop"] — prop follows a semicolon and space Custom property names always start with --, so they can never appear right after a semicolon or at the start of the style string without the -- prefix. Real border declarations can. Fixes WordPress#70211.
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @Kgupta62. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. 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. |
github-actions
Bot
added
[Package] Block library
|
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @Kgupta62! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
t-hamano
added
the
Global Styles
|
Closing the loop here a bit to link this back to where this approach was proposed: #75546 (comment) One thing this PR description doesn't touch on is the increased CSS payload being delivered on every request for this fallback. |
There was a problem hiding this comment.
Thanks for the PR! 👍
I've taken a closer look at this approach and it holds up well for the most part.
The more precise substring selectors genuinely fix the CSS var false positives while also addressing the most common URL-in-value edge cases. I don't think remaining edge cases, like weird spacing (double spaces etc) or substrings in URLs matching these selectors, are worth optimising for.
I also looked into the CSS payload effect. Relatively, this would almost double the size of common.css. That said, while it might look significant the absolute increase is effectively noise (<1kB) in the context of the broader bundle especially after gzip given the repeated tokens.
The existing inline comment before these fallback styles says that they could or should be removed once intelligent defaults can be set while adjusting the border block support controls. This might actually be possible now, at least close enough to remove these fallback styles long term.
We have access to global styles data in the block editor now. Recent work around displaying inherited global styles also shows we should be able to determine the border style required whether its source is a global, block type, or block style variation style.
I'll see if I can investigate this editor-only fix today. My only concern there is if some sites would then rely on the old fallback styles and it might result in a further visual regression.
@talldan I believe you have also taken a brief look at this issue. Any thoughts?
In the meantime, I'd be happy to proceed with merging this, if others are, once the unrelated @media whitespace change is reverted.
Thanks again @Kgupta62 for implementing the fix and getting this PR up 🙇
| Before | After |
|---|---|
 |
 |
I'd echo your thoughts. The fix looks good to me, thorough work here. If there's possibility in the long term that this becomes only a temporary measure then even better 👍 |
aaronrobertshaw
added
Backport to WP Minor Release
aaronrobertshaw
left a comment
aaronrobertshaw
left a comment
There was a problem hiding this comment.
I've given this another quick smoke test and is working for me, excluding the known extreme edge cases.
Let's merge this for now. I'll continue looking at potnentially removing all of these fallback styles tomorrow.
|
Congratulations on your first merged pull request, @Kgupta62! We'd like to credit you for your contribution in the post announcing the next WordPress release, but we can't find a WordPress.org profile associated with your GitHub account. When you have a moment, visit the following URL and click "link your GitHub account" under "GitHub Username" to link your accounts: And if you don't have a WordPress.org account, you can create one on this page: Kudos! |
|
There is a rough draft up in #78818 that explores alternative approach, removing CSS fallbacks and adding edit and render time fallback style injection to blocks. I've run out on time for this but will revisit it next week. |
4 participants
What?
Tightens the CSS attribute selectors in
common.scssthat apply defaultborder-style: solidwhen border properties are detected in inline styles.Why?
Fixes #70211.
The selectors
[style*="border-width"]and[style*="border-color"]use substring matching (*=), which matches any inline style containing those strings — including CSS custom properties like--my-border-width: 1pxor--fir-list-border-color: red.This causes
border-style: solidto be applied to elements that have no actual border set, producing unwanted visible borders on custom blocks and themes that use custom properties with "border" in their name.How?
Implements suggested fix in #75546 (comment).
Replaced each
[style*="prop"]selector with three more precise selectors:[style^="prop"]propis the first declaration in the style[style*=";prop"]propfollows a semicolon (no space)[style*="; prop"]propfollows a semicolon and spaceCSS custom property names always begin with
--, so they can never appear directly after a semicolon or at the start of the style attribute without that prefix. Real CSS property declarations can.All selectors remain inside
:where()so specificity is unchanged.Testing Instructions
Add a block or HTML with a custom property containing "border-width" or "border-color":
Before: Both divs get
border-style: solidapplied (unwanted border visible)After: No border appears on either div
Verify real borders still work:
Confirm the red border is still applied correctly