Layer everything, so priority levels are really clear. Maybe allow unlayered CSS for super powerful overrides only, but ideally even do that as a high-level layer.

I think this is it.

I started writing CSS2 stylesheets in 2003 but had only passing familiarity with JS until 2013-15 (progressing modestly until 2018).

Because I had 10-12 years more experience in CSS, even when I got my head around scope in JS, I didn’t get what the big deal was about not casually putting things (some things, many things, everything) in global scope.

In hindsight, it occurs to me this was because in a CSS stylesheet – the paradigm I was much more familiar with – everything (unless you count media queries as quasi-scoping) is in global scope.

So I globally scoped my JS in the same way I globally scoped my CSS – and learned better only later.

But with the introduction of CSS Cascade Layers, there is now a CSS global scope: unlayered styles.

So, in the same way globally scoped variables appear only rarely in JS Best Practice, in some potential future CSS Best Practice @layer will be deployed everywhere to ensure globally scoped styles appear rarely, too.

This approach would mean that, absent very good reason, no styles should be unlayered and, instead, CSS Cascade Layers would become a mainstay of most stylesheets, alongside e.g. CSS Custom Properties and Touchscreen Media Queries.

The question “But when should I use @layer?” (somewhat) recalls the question “But when should I use const?” after the introduction of let and const in ES2015.

Only when a more progressed understanding evolved, did many ES2015 devs reframe that question as: “When shouldn’t I use const?”:

So maybe that’s it. Maybe instead of asking when we should use Cascade Layers we will benefit greatly by adopting @layer across the board and recognising that the more important question any of us could ask is:

“When shouldn’t I use @layer?”

But, if you can create a layer anywhere in your code, doesn’t it mean that it’s gonna be a feature duplicating functionality of z-index?

You don’t need to declare your layer first, so you don’t need to worry about that.

If you want to override a layer, just have your layer after it, just like the usual cascading override that gave its name to CSS.

And since unlayered rules now take priority in the last draft (october 2021), it seems to be going to be even easier.

Perfectly said.

Some Saas software allows you to add your own custom CSS to “theme” the app atop a base css theme – which can’t be removed. A lot of the time their choice of CSS selectors leaves a lot to be desired. @layers makes perfect sense in this instance, you can just wipe that clean and start fresh. Unless I’ve got my layers crossed ;)

we’re far from a11y experts, but are thinking a lot about browser extensions and the like, and think this should be a net-positive in the long run, but might take some re-writing of scripts in the short term. in the future, it should be easy to write user styles in a higher layer, such that your styles are always applied.

It sounds like they are something similar to namespaces. We will be able override thing in scope of particularly namespases.

But… What is the problem they are trying to solve in the first place?

Exactly. The problem with !important is it was declaration-specific, and might pop up in any ol’ context of the cascade, obliterating other specificity factors in the process.

@layer is a farcry from that. It lets you manage specificity in god mode at a macro scale. We’ll be able to take a project’s entire architecture into consideration, setting outer boundaries for specificity, but then letting “members” of individual layers duke it out from there.

Definitely looking forward to this.

However, I think it’s also too narrow of a comparison. If your CSS is pretty static over time and you control all of it, then layers might not bring a huge benefit (though, that is yet to be seen since it offers a new structural aspect to CSS).

But, if you are using 3rd party CSS or an internal shared bit of CSS, layers allow those styles to be simplified (eg look at Bootstrap’s styles which have !important everywhere) because they can rely on the developer putting their own CSS in a lower layer, or eventually they could ship their CSS in a predefined layer and let developers position it within their CSS hierarchy as needed.

I think layers will remove the need for !important within our own CSS and within 3rd party CSS. It adds another dimension to the cascade that works at the macro scale, which lets us use selector specificity and selector order to tune things at the micro scale.

I think this is a great feature!

Yeah, that doesn’t seem like a good thing. Feels like it’s introduce the same sort of problems as adding !important to everything.

Also, in that example, could you not just repeat a class to increase the specificity?