Common CSS: avoid false-positive border-style on custom properties

[Kgupta62]

What?

Tightens the CSS attribute selectors in common.scss that apply default border-style: solid when 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: 1px or --fir-list-border-color: red.

This causes border-style: solid to 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:

Selector	Matches when...
[style^="prop"]	prop is the first declaration in the style
[style*=";prop"]	prop follows a semicolon (no space)
[style*="; prop"]	prop follows a semicolon and space

CSS 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

1. Add a block or HTML with a custom property containing "border-width" or "border-color":

   <div style="--my-border-width: 1px; padding: 10px;">Should have no border</div>
   <div style="--fir-list-border-color: red; padding: 10px;">Should have no border</div>

2. Before: Both divs get border-style: solid applied (unwanted border visible)

3. After: No border appears on either div

4. Verify real borders still work:

   <div style="border-width: 2px; border-color: red;">Should have a red border</div>

5. Confirm the red border is still applied correctly

[github-actions]

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 props-bot label.

Unlinked Accounts

The 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.

Unlinked contributors: Kgupta62.

Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: Rishit30G <rishit30g@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: mateuswetah <tainacan@git.wordpress.org>
Co-authored-by: EdithAllison <terragirl@git.wordpress.org>
Co-authored-by: firdaus666 <firdaus666@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 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.

[aaronrobertshaw]

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.

[aaronrobertshaw]

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

[talldan]

@talldan I believe you have also taken a brief look at this issue. Any thoughts?

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]

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.

[github-actions]

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:

https://profiles.wordpress.org/me/profile/edit/

And if you don't have a WordPress.org account, you can create one on this page:

https://login.wordpress.org/register

Kudos!

[aaronrobertshaw]

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.