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

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.

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:

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.

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

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.