Sorry, a small typo there. For load-css(), you need the built-in ‘meta’ module from Sass:

@use 'sass:meta';

@layer bootstrap {
  @include meta.load-css('~bootstrap/scss/bootstrap');
}

I don’t know what version of Sass you are using, but Sass doesn’t have any special handling for layers. So it is likely treating your import as a CSS-import (rather than a Sass-import) because it has non-Sass syntax.

If ~bootstrap/scss/bootstrap provides both Sass features (mixins, variables, etc) and also has direct CSS output, those will need to be handled a bit differently. You want to put the CSS-output into a layer, but keep the Sass features available anywhere. That should be possible using Sass modules and more specific Bootstrap paths. Something like…

Forward all the Sass features from one file:

// bootstrap-sass.scss
// Use the configuration syntax as needed
@forward "~/bootstrap/scss/functions";
@forward "~/bootstrap/scss/variables";
@forward "~/bootstrap/scss/maps";
@forward "~/bootstrap/scss/mixins";

Then in your main file, you can @use the Sass features you’ve forwarded, and load the CSS from bootstrap separately:

// main.scss
@use 'bootstrap-sass' as bs;

@layer bootstrap {
  @include load-css('~bootstrap/scss/bootstrap');
}

.example {
  @include bs.border-end-radius($alert-border-radius);
}

You can use all: revert-layer to roll back all layer styles, similar to using all: revert to roll back author styles.

Media queries can absolutely change layer order. The @layer rules are allowed inside media-queries, and then only impact the order of layers when the media-query is applied. You could do something like:

@media print { @layer my, print, layer, order; }
@media screen { @layer my, screen, layer, order; }

Having a play around with cascade layers for a new project and I seem to be getting an ‘Undefined mixin’ error when providing bootstrap with its own layer like so:

`// Layers order
@layer bootstrap, theme, utilities, third-party;

// Variables
@import “1-variables/app”;

// Theme mixins
@import “2-mixins/badge”;
@import “2-mixins/button”;
@import “2-mixins/modal”;
@import “2-mixins/switch”;
@import “2-mixins/tabs”;
@import “2-mixins/theme”;

// Bootstrap
@layer bootstrap {
@import “~bootstrap/scss/bootstrap”;
}

// Theme components
@layer theme {
@import “3-components/accordion”;
@import “3-components/alert”;
@import “3-components/avatar”;
}`

Or even:

@import '~bootstrap/scss/bootstrap' layer(bootstrap);

The error:

ERROR in ./resources/sass/phoenix/phoenix.scss
Module build failed (from ./node_modules/laravel-mix/node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
SassError: Undefined mixin.
╷
26 │ @include border-end-radius($alert-border-radius);

If I then import bootstrap outside of a layer, the project builds fine.

As you can see the order of my layers states that bootstrap is first, so this is odd to me.

Has anyone else ran into this issue?

Hi Mark, in theory the answer is ‘yes’ – since any styles from anywhere can be added to a layer. But the practical answer probably depends a lot on the exact tool-chain being used to ship your components, and also the tool chain used to apply them. I can’t speak to that without a lot more detail, and even then there’s a limited set of tools I have experience with. I would file an issue with whoever is shipping the components, to see if they have advice.

All new features are broken in old browsers, there’s no way to avoid that. The backwards-compatibility requirement is that new features shouldn’t break old CSS in any browser.

In this case, as with media-queries, any code inside an @layer will be hidden from old browsers. And there’s a polyfill in development which would be able to generate and link a legacy stylesheet automatically. It’s not an ideal situation, but it is a temporary one.

I wasn’t a huge fan of this feature either (see my comment above), but your comment made me think and I now realize what goal layers are supposed to serve.

At first glance it seemed that layers provide a method to “enclose” badly-written or half-compatible CSS modules so that everything in there has low priority and everything you write on top of it overrides it. I had concerns about the compexities involved, but I saw the point. Your (pretty good) points made me realize that this is not at all what layers are for.

Instead, layers can serve such CSS modules that were written with layers in mind. They don’t serve the module client, they serve the module author! Now, the module author can use whatever selector sequences that work inside the logic of their own module, and don’t worry about the module client having to deal with their selectors later, because the layering system takes care of that.

With this in mind, I get the point of !important with the layer-reversal mechanism. As Miriam pointed out, !important can now be seen as deprecated as a tool for overriding previous CSS rules. Using it in such sense inside a layered module would cause absolute mess.

Instead, !important communicates “this declaration is essential for the module to work correctly. It must be resistant against any future unknown declarations and you must not override it in a subsequent module”. Now it makes sense that the mechanism actively prevents subsequent modules from overriding the important declaration. The module client can decide to override it anyway, but that would only be possible with a dedicated “overrides” layer, not with some accidental code.

If you look at these then use-cases (https://noti.st/jensimmons/QOEOYT/three-topics#syyV24S) you will see that CSS Layers does not solve a single one of these problems. I think they thought there would be different origins and that there is no cascade between these origins. Now we have layers, with the cascade.

So you can’t really refactor old styles. The old styles will always cascade into the new styles, so you always have to overwrite them again. Yes, you can do that with a lower specificity, but other than that, there is nothing to gain, that the source code order couldn’t do. On top of that you can’t run the old styles with the new styles in parallel, because part of the new styles (with the lower specificity) wreak havoc inside the old styles.

Same with the third party stuff, if they are writing bad css, then there might be an !important some where. To override some of the styles you have a layer below the third party layer, but for the !important override you need another layer on top the third party layer. I think that’s adds to the complexity and maintainability. Especially if the solution would be to copy the selector and put it later in the source code order. As simple as that.

It shows that there are only limited real use cases. In the last view weeks all the blog entries I’ve read about CSS Layers, all have these constructed theoretical examples. Which show how the layers work, but they don’t show a real world use case.

Cons
– Adds complexity
– Harder to maintain
– Side effects from too generic selectors (specificity is there for a reason)
– Screws with the source code order (spaghetti css code)
– CSS parsing got slower

Pros
– Easy to override existing styles even with a lower specificity.

CSS Layers sound very good on paper, but in the real world they are of limited use. Right now they solve no problems we couldn’t solve with the tools we already have. But instead they create new pitfalls and confusion about the cascade, specificity and importance. They make CSS harder to learn. They add a layer of confusion (sorry for that ).

Now every time a css file is parsed, time and energy is being wasted for so little gain. It feels like bloat and featureritis.

Hi all, I think you’re right to highlight importance-reversal as a potential point of confusion for authors, and I also hope that MDN draws more attention to it. I expect their page will get some updates now that the feature is rolling out in browsers, and is no longer theoretical. But, as always, that will require some time and attention (documentation isn’t magical, but they do accept issues/requests and PRs).

Part of the confusion is that web authors have primarily used !important as a hack for overriding specificity, while it serves a different purpose in the overall cascade. So in some ways you can think of this change as ‘deprecating’ the importance hack that authors have been using, and replacing it with an explicit layering feature. There will be some complications to manage during that transition period, but otherwise I expect authors using layers will want to start removing important flags that were used in that way — as specificity overrides.

If you only think of importance as that simple specificity-override hack, then the layer-reversing behavior looks very confusing. It doesn’t make any sense for that use-case! But once we consider that use-case deprecated… We’re still left with the original purpose of the importance feature. Authors are not the only ones using CSS, and !important is still useful and necessary as a balancing mechanism between origins — a use-case that also makes sense in relation to layers. Not as a simple priority-bump (you can use a new layer for that), but as a way to mark that some styles are actually required for a selector pattern to work as intended. That use-case still exists, and can be quite useful — and I think the layer-reversing behavior matches that use-case fairly well.

My point is: the same feature can be confusing for one use-case, while being helpful in another. And it can be (unofficially) ‘deprecated’ for one situation, while it is still necessary & useful in other cases. So yes, I agree that this will be a confusing adjustment for folks who are used to the old (author-centered) pattern. But I also think this provides a very powerful new pattern that people could learn to use in their design systems to great effect.

I hope authors take the time to learn the use-case and mental-model for how importance was meant to be used, rather than simply throwing it out now that the old mental-model no longer fits.

It does not defeat the cascade. The cascade still happens. Out of the entire cascade, you’ve only flattened ‘specificity’, and only within the author normal and important origins. To do that, you had to give up on a lot of powerful selector combinations, add a lot of unique classes (using extra dependencies to ensure that uniqueness), and maintain a strict ‘order of appearance’ wherever internal cascade conflicts are still possible.

You can do that, but it’s only simpler in that you are deciding not to take advantage of any other, more explicit cascade-management tools that CSS provides. Like simplifying a toolkit down to hammers only, because screwdrivers add complexity. But then you replace that language ‘complexity’ (features) with the extra complexity (features) of build tools like css modules, and unique class conventions. Because you understand that additional language/tooling complexity can be used to make our actual code more clear, explicit, and intentional.

You are welcome (of course) to use the tools that you like best for managing the cascade. But as long as you are using CSS in any way, the cascade remains unavoidable, and undefeated.

So if you’re looking for a Chromium-based browser that’s specifically built for developers and has support for @layer that also shows them in its devtools, check out Polypane.

Here’s a quick screenshot showing it in action, there’s support for named and unnamed layers as well as nested layers: