Nice catch! Got that all cleaned up. ✨

If I understood the article correctly, this could be the way to deal with that:

@layer important, default, utilities

Now if I use your example again:

@import url(blabla.css) layer(utilities);

And blabla.css contains some style with !important, we should be able to override that with another important style in the the important layer?

Great stuff! Currently applying cascade layers to a new project. About !important: I find that using cascade layers all but elimininates the need for that, even proactive use such as overrides.

It’s also included in postcss-preset-env: https://preset-env.cssdb.org/features/#cascade-layers

The fact is, the minute you modify any element in your author sheets, like div, p, span, etc., you can never override them using layers using any cascade, specificity. etc. And most modern web developers create ‘reset’ sheets to change their element designs. So layers die.

The sad reality is, pre-processors, variables, layers, and other new web tech was designed by people that never understood how cascading style sheets work and how text-based properties inherit. If they did, they would see that hey never need those tools. You don’t need to change things that inherit, say from the body element of a typical web page. And when you do, you already have a weighted and origin-like, layer-like system using ID and Class that works exactly the same as sheet origin and layer origin precedence with a fraction of the CSS code needed!

Example, any HTML modified by ID can never be overridden by a more weighted set of classes. They remain in their own layer, essentially.

This is why CSS has worked perfectly for 20+ years and rarely every changes or needs to change.

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.