[css-cascade] A way to escape the current cascade layer and render styles in the parent layer (@layer ..)
#11010
Comments
|
Wouldn’t that defeat the purpose of having layers in the first place? |
|
@flashymittens – How so? In the example I gave, layers are still useful as a way to define precedence when we can't / don't want to rely on specificity. /* assume this stylesheet is imported in the `utilities` layer */
.dark .bg-primary {
background-color: red;
}
@layer ../overrides {
[forced-bg="blue"] {
background-color: blue;
}
}<body class="dark">
<div class="bg-primary" forced-bg="blue">This should be blue</div>
</body>(Of course this is a silly example, but hopefully you get what I mean.) |
|
I think the proper way would be for tailwind (as a style vendor) to organise its styles into a more specific cascade layer. @layer utilities.tailwind {
color: green;
}Then you can write your own utilities as: @layer utilities.my-styles {
color: purple;
}And organise your layers freely with: @layer utilities.my-styles, utilities.tailwind;@layer utilities.tailwind, utilities.my-styles; |
|
Well, Tailwind generates the CSS for utilities (including the custom-defined ones) on demand based on config + usage in the markup. There's an almost unlimited number of potential utility classes, since they can be modified with any number of "variants" (e.g. |
|
I see this feature request as a more precise |
|
It seems to me like this issue is tool-specific, and the solution should be provided by that tool. The ideal solution here is that you specify what layer each selector is in, instead of having a default that you need to break out of. That's already how things work, if a third party wasn't writing (and layering) all your layers for you. I'm not sure we can solve problems created by specific tools, unless there's some real good reason the tools themselves can't provide a solution. Could this become a Tailwind syntax, rather than being added to CSS? It seems to me like that should be possible. |
|
Thanks for the feedback everyone. I'm going to close this and hope that #6323 gets addressed at some point, as it will also provide a (less direct) solution to my use case (assuming Tailwind doesn't introduce some specific feature for it, which I think is more unlikely). |
mirisuzanne
added
the
Closed as Question Answered
|
Thanks @benface - feel free to reopen at some point if it seems like there are more use-cases we should be considering here. |
My use case is a framework that lets you generate styles in a particular layer. For instance, Tailwind CSS v4 generates all the utility classes in a
utilitieslayer (which I can customize). If I want some utilities to have lower precedence than others, I can wrap them in another layer since unlayered styles beat layered styles. But if I want some utilities to have higher precedence than others, I am forced to resort to specificity hacks (e.g.:is(#a, .my-actual-selector)). It would be nice if I could wrap them in@layer ..overridesand they would win because I would defineoverridesafterutilities.The text was updated successfully, but these errors were encountered: