&__element (BEM-style nesting) compiles to invalid selector :is(.block)__element in v4.3.3

[ondrej-kaspar]

Since the native CSS nesting handling was introduced in v4.3.0 (#20124), the following input:

.block {
  &__element {
    color: red;
  }
}

compiles to:

:is(.block)__element {
  color: red;
}

which is invalid CSS — :is() cannot be directly concatenated with an identifier like that.

Expected behavior

Since & is immediately followed by an identifier (no combinator or pseudo-class), it should be treated as a compound selector and produce:

.block__element {
  color: red;
}

This is how it worked before v4.3.0 when nesting was resolved by Lightning CSS, and how &:hover-style nesting (with a pseudo-class after &) still correctly resolves to :is(.block):hover.

Environment

Tailwind CSS v4.3.3

Reproduction
https://play.tailwindcss.com/nLeNDYZr4j?file=css

[wongjn]

Could you provide a git repo where it was working? In Lightning CSS playground (i.e. before 4.3), it compiles to:

__element.block {
  color: red;
}

And in Vite with 4.2.4 I get:

__element.block{color:red}

Regardless, the nesting was always meant to follow native CSS behavior and not Sass-like behavior.

[ondrej-kaspar]

@wongjn the same code was working with version 4.3.0, when I upgraded to the latest version (4.3.3), compiled CSS was broken (I haven't tried 4.3.1, 4.3.2).

I'm using postcss-nested plugin.

[wongjn]

Right, I see it as relying on incompatible behavior, like #20358. You could consider:

• Not using the incompatible nesting syntax.
• Using a Tailwind version that works with your code base.
• Writing minimal CSS - the Tailwind paradigm is to use utility class names in markup directly as much as possible. For components, consider using your templating engine instead of CSS.

[VivensB]

This is not postcss-nested, and the regression is narrower than the thread suggests. It landed in 4.3.3 specifically.

I reproduced it with @tailwindcss/postcss alone, no postcss-nested installed at all:

.block {
  &__element { color: red; }
  &:hover { color: blue; }
}

/* tailwindcss 4.3.3 */
:is(.block)__element { color: red; }
.block:hover { color: blue; }

Bisecting the same input across versions:

version	&__element becomes
4.2.4	&__element (left unresolved)
4.3.0	&__element (left unresolved)
4.3.1	&__element (left unresolved)
4.3.2	&__element (left unresolved)
4.3.3	:is(.block)__element

So through 4.3.2 Tailwind passed this nesting through untouched, which is why @ondrej-kaspar's setup worked: postcss-nested got it afterwards and expanded it Sass-style. Confirmed both ways with postcss-nested 8.0.1 in the pipeline:

tailwindcss 4.3.2 + postcss-nested  ->  .block__element
tailwindcss 4.3.3 + postcss-nested  ->  :is(.block)__element

Plugin order does not change that, since the Tailwind plugin compiles the file itself rather than handing an AST along. postcss-nested on its own still resolves it correctly to .block__element.

On the Sass versus native question. @wongjn is right that this should follow native CSS, and native CSS does not concatenate: &__element is a compound of the nesting selector and a type selector named __element. But that does not make the current output correct, because a compound selector has to put the type selector first. :is(.block)__element is not valid CSS in either reading. The native-correct result is __element:is(.block), which is exactly the shape Lightning CSS produced as __element.block.

Worth noting the failure is silent. Through @tailwindcss/vite on 4.3.3 the rule is dropped from the build output entirely, while &:hover and & .child from the same block survive, so nothing warns you that a rule disappeared.

For anyone hitting this now, 4.3.2 is the last version that works with a postcss-nested setup, and writing .block__element explicitly avoids it on any version.

Reproduced on Node 22, Linux x64, @tailwindcss/postcss and @tailwindcss/vite both at the versions above.

[RobinMalfait]

PostCSS doesn't run plugins in order because they are using a visitor-like API instead.

If you were using a production build that triggered Lightning CSS, then

.block {
  &__element { color: red; }
}

Would've been turned into:

__element.block {
  color: red;
}

For normal builds, prior to Tailwind CSS 4.3.3, it was left untouched. As mentioned before, we did always "require" valid CSS, and .block { &__element { … } } is invalid native CSS.

If you want to keep using the postcss-nested plugin, you have to make sure that it's executed before Tailwind CSS sees it. You can try doing something like this in your postcss.config.js file:

const postcss = require("postcss");
const postcssNested = require("postcss-nested");

module.exports = {
  plugins: [
    {
      postcssPlugin: "postcss-nested-first",
      Once(root, { result }) {
        return postcss([postcssNested()]).process(root, {
          from: result.opts.from,
        });
      },
    },
    require("@tailwindcss/postcss"),
  ],
};

Let me know if this works for you

[VivensB]

Thanks @RobinMalfait, the visitor API point explains the thing I could not account for. I had tried postcss-nested on both sides of Tailwind and got :is(.block)__element either way, and concluded the plugin must be compiling from source rather than passing an AST along. Plugins not running in sequence is the actual reason, and the wrapper you posted is the right shape for forcing the order.

Recording the version detail for anyone who lands here from a search, since it is the part that makes this look like a regression rather than a config problem: through 4.3.2 the nesting was passed through untouched, so a postcss-nested setup kept working by accident. 4.3.3 is the first version that resolves it, which is why the upgrade broke it.

Agreed that .block { &__element { … } } is not valid native CSS and that relying on it was always fragile.

[nisargpatel7042lva]

Why this happens

Tailwind CSS v4 replaces the legacy PostCSS/Sass preprocessing pipeline with an engine built on top of native CSS Nesting (via Lightning CSS).

In the native CSS Nesting specification:

• The & nesting selector represents an element reference (desugared conceptually to :is(...)), rather than a raw string-concatenation token.
• Writing &__element in native CSS parses into :is(.block)__element, which is an invalid CSS selector in all modern browser implementations.

---

How to Fix

1. Write the explicit compound selector (Recommended)

Because Tailwind v4 scans and handles standard CSS classes efficiently, writing the full BEM selector without prefix concatenation is the cleanest and most performant approach:

@layer components {
  .block {
    /* base block styles */
  }

  .block__element {
    /* element styles */
  }
}

2. Define it with @Utility

If you are declaring reusable utility styles directly in your CSS files:

@utility block__element {
  /* your styling rules */
}

(Note: If your project structure strictly mandates Sass-style string concatenation with &__, you will need to run a dedicated preprocessor like sass before the Tailwind v4 build step).

[Mr-Hasan-Hamid]

This happens because Tailwind v4 switched to native CSS nesting rather than using Sass-like string preprocessing.

Under the native CSS Nesting Module Level 1 specification, the & selector represents the parent selector wrapped in :is(). Native CSS nesting operates on selector ASTs, not string token concatenation. Because of this, writing &__element evaluates to :is(.block)__element, which is invalid according to the CSS Selectors Level 4 spec (you cannot directly append an identifier suffix to a pseudo-class).

In v3 and early v4 builds, Lightning CSS or Sass did raw string interpolation (.block + __element), but with pure CSS nesting that BEM shortcut isn't valid CSS.

For now, the workaround in v4 is to write out the full class name (.block__element) or run a preprocessor step if your project relies on Sass-style suffix expansion.