Ability to run Lightning CSS on Vite serve

[janko]

When I'm using the @tailwindcss/vite plugin, the CSS I get in development is not the CSS I get when building for production. With the Vite dev server, the compiled CSS doesn't appear to be run through Lightning CSS, as CSS is still nested.

This would be fine if the nested CSS was equivalent to the un-nested CSS, but it's not. I've encountered issues where different rules are winning the specificity war in the nested version, causing the design to break.

For example, in this flattened version, the link will be blue on hover:

<a class="btn-primary">Link</a>

.btn-primary:hover {
  color: blue;
}

a:hover, .link-primary:hover {
  color: red;
}

However, in the nested (non-transpiled) version the link will be red on hover:

.btn-primary {
  &:hover {
    color: blue;
  }
}

a, .link-primary {
  &:hover {
    color: red;
  }
}

If Lightning CSS is as fast as the authors claim, I should be able to run it in development without significant performance impact, right? Or are there other blockers?

For background, I'm trying to migrate our Sass code to pure Tailwind + Lightning. So, it would be great if my CSS was un-nested in development, just like it was with Sass.

[wongjn]

In the flattened version, I would expect it to be red on hover, the same as the nested (non-transpiled) version. Do you have a reproduction that is showcases the behavior you describe please?

[janko]

Yeah, I would also expect the same rules to win in the nested version, I was surprised it wasn't equivalent. Here is an example – https://play.tailwindcss.com/zG93AhmZEa. I didn't even import Tailwind, to make it clear that this is default browser behavior.

I'm on Chrome 138.0.7204.93 (Official Build) (arm64), in case that helps.

[janko]

One could argue that we shouldn't be relying on competing rules where nesting can tip the scale (I found 2 such examples in our codebase so far), and I agree it's not well-designed CSS. But I would first like to migrate to Tailwind without regressions, and then start fixing/compressing our CSS.

[wongjn]

Oh, I see. It seems like nesting is actually more like :is(a, .link-primary):hover than
a:hover, .link-primary:hover.

[adamwathan]

Hmm when I test your example in the Lightning CSS playground it compiles how I'd expect, using :is(...) to preserve the correct specificity:

Playground demo

Can you share a reproduction by any chance?

[janko]

Yeah, it's the same in our app. It was just my assumption that Lightning CSS would un-nest it as a:hover, .link-primary:hover, but I didn't actually bother to check 🙈

So, the problem is simply that our current CSS needs to be updated to handle different CSS nesting specificity rules. Thanks for helping me figure that out 🙂