The common.css file [style*=border-width] selector is applying unwanted styles

Description

Description:

In the file common.css from the Gutenberg plugin, there's a global selector:

html :where([style*=border-width]) {
  border-style: solid;
}

This selector unintentionally matches inline styles containing custom CSS variables such as:

<div style="--fir-list-border-width: 1px;"></div>

…which results in the element receiving border-style: solid, even though no actual border-width property is defined. This causes unwanted borders to appear in custom blocks and themes using custom CSS variables.

Step-by-step reproduction instructions

Add a block with inline custom property like:
<div style="--my-custom-border-width: 1px;"></div>
Observe that border-style: solid is applied to the element.

Expected Behavior:

The selector should only apply border-style: solid if a real border-width is declared, not when custom variables containing the substring border-width are used.

Suggested Fix:

Avoid using broad attribute selectors like [style*=border-width]. Instead:

Use class-based targeting if possible.
Or use stricter matching logic (e.g., regex-like match for actual property names).

Workaround:

Add border width 0 to border wrapper options, …but this should not be necessary, as the default border should be none, if the border option is not set.

Screenshots, screen recording, code snippet

Environment info

WordPress version 6.8.1
Gutenberg Version 20.8.0

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

Please confirm which theme type you used for testing.

Block
Classic
Hybrid (e.g. classic with theme.json)
Not sure

Thanks for sharing the issue,
I was able to reproduce it locally. We could consider using a regex like /\bborder-width\s*:/ to more accurately match declarations such as border-width: 1px.
However, I’m curious about the other border-related styles defined in common.scss, introducing separate logic specifically for border-width might lead to inconsistency with how other border properties are handled.

We could consider using a regex like /\bborder-width\s*:/ to more accurately match declarations such as border-width: 1px.

I think the CSS selector only allows limited pattern matching, and we can't use regular expressions.

Admittedly, the current implementation is a bug, but for now, our only solution might be to use non-pattern-specific variable names or to override the unintended style.

I think the CSS selector only allows limited pattern matching, and we can't use regular expressions.

Agreed, my intension for this was using JavaScript, as for the CSS pattern matching we are limited to ^ ( starts with ), $ ( ends with ) and * ( contains )

Thanks everyone for responding to this.

The solution is indeed simple, just change --my-custom-border-width to --my-custom-borders-width.

I realize this is probably a minor bug, but it can be confusing just because CSS variables can trigger unwanted visual side effects.

Maybe in the future this can be considered for a fix, or at least documentation or exceptions.

The fundamental solution to this problem would be to rework the global styles logic and not use potentially conflicting selectors, or wait until CSS supports regular expressions.

For now, I'll leave this issue open.

Thank you for opening this issue.

Just passing here to tell that I'm facing issues related to this.

I use a block from a plugin. That block has in it's wrapper the following CSS: --tainacan-input-border-color: var(--tainacan-gray1);. When I insert that block in any page having the Gutenberg plugin activated, a border is added to the entire wrapper (when the variable itself is about an element inside the block - the input).

I don't think changing the input variable in the plugin code is something ok to ask, they already had the care to add namespacing to it. Its the rule:

html :where([style*=border-color]) {
  border-style:solid
}

from common.css that is too generic.

But I understand that it seems that there's no easy solution by now. Hope you guys can figure something one day!

It seems that the bug makes its way into Core :(

Seeing the issue on WP 7.0 RC

@mateuswetah

@mateuswetah Yes the current solution is to change the code so that it is not the same as the core.

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

There's some reports in the forums for this issue too - https://wordpress.org/support/topic/unremovable-borders-since-last-wp7-11-release-may-20-2026/.

It might be good to backport any fix to a WordPress minor release.

Adding a real-world reproduction case from Avada (Fusion Builder) to illustrate the scale of this issue.

How Avada is affected

Avada outputs inline CSS custom properties on layout elements via its Fusion Builder. These custom property names contain the same substrings targeted by the broad selectors in common.css. Two confirmed triggers on a default Avada install:

--awb-border-color: var(--awb-color1);
--awb-box-border-color-hover: var(--awb-color4);

Because [style*=border-color] is a substring match, both of these trigger border-style: solid on the containing element, producing visible borders that were not configured and did not exist before the update.

All ten selectors are at risk

Avada's custom property naming convention uses border-color and border-width as components in compound names throughout its design system. Based on the naming pattern alone, all ten selectors in common.css are plausibly affected:

html :where([style*=border-color])        /* --awb-border-color, --awb-box-border-color-hover */
html :where([style*=border-top-color])    /* --awb-border-top-color */
html :where([style*=border-right-color])  /* --awb-border-right-color */
html :where([style*=border-bottom-color]) /* --awb-border-bottom-color */
html :where([style*=border-left-color])   /* --awb-border-left-color */
html :where([style*=border-width])        /* --awb-border-width, --awb-box-border-width */
html :where([style*=border-top-width])    /* --awb-border-top-width */
html :where([style*=border-right-width])  /* --awb-border-right-width */
html :where([style*=border-bottom-width]) /* --awb-border-bottom-width */
html :where([style*=border-left-width])   /* --awb-border-left-width */

The width selectors carry additional risk: because they set border-style: solid without a corresponding border-color, the browser falls back to the element's current text color, producing dark outlines that are more visually disruptive than a transparent border would be.

Workaround in use

The site-level workaround is to override the rules in the theme stylesheet using the --awb- prefix as a distinguishing selector:

html [style*="--awb-"]:where([style*="border-"]) {
  border-style: initial;
  border-top-style: initial;
  border-right-style: initial;
  border-bottom-style: initial;
  border-left-style: initial;
}

This works because :where() contributes zero specificity, so any selector with real specificity wins. It is functional but it is a theme-level patch for a core problem, and it does not scale: every plugin or theme using CSS custom properties with "border" in the name needs its own override rule.

Supporting the PR fix

The approach in PR #77476 using [style^=prop], [style*=";prop"], and [style*="; prop"] correctly addresses the root cause. Custom property names always begin with --, so they cannot appear at the start of a style attribute or immediately after a semicolon without that prefix. Legitimate border declarations can, so the three-part pattern correctly distinguishes between the two.

Please note: Code Analysis was done with Claude AI, but the bug was verified by a human (me); and tested on a Staging copy of a live Avada site. The bug affects the main header navigation and is very noticeable.

Update

Avada have released a patch.

Ran into the same issue. In my case, the issue was triggered by an element with the inline style: transition-property: border-color;
which matched the selector and caused border-style: solid to be applied.

@qarayahya

@qarayahya if you have the chance, can you confirm if you experience the issue in the latest Gutenberg with the tightened CSS fallback rules in #77476. Otherwise, there's an alternative approach that removes these fallback styles entirely in #78818 that would be good to also test against.

Navigation Menu

Repository navigation

The common.css file [style*=border-width] selector is applying unwanted styles #70211

Description

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

Please confirm that you have searched existing issues in the repo.

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Please confirm which theme type you used for testing.

How Avada is affected

All ten selectors are at risk

Workaround in use

Supporting the PR fix

Update

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The common.css file [style*=border-width] selector is applying unwanted styles #70211

Description

Description

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

Please confirm that you have searched existing issues in the repo.

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Please confirm which theme type you used for testing.

Activity

Rishit30G commented on May 26, 2025

t-hamano commented on May 26, 2025

Rishit30G commented on May 26, 2025

firdaus666 commented on May 28, 2025

t-hamano commented on May 29, 2025

firdaus666 commented on May 29, 2025

mateuswetah commented on Mar 4, 2026

mateuswetah commented on Mar 31, 2026

firdaus666 commented on Apr 9, 2026

talldan commented on May 22, 2026

EdithAllison commented on May 26, 2026

How Avada is affected

All ten selectors are at risk

Workaround in use

Supporting the PR fix

Update

qarayahya commented on Jun 14, 2026

aaronrobertshaw commented on Jun 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions