Re: [csswg-drafts] [css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order (#6323)

> There are three approaches that keep coming up (with minor variations of syntax). All of them have potential, and all of them have issues:
> 
> 1. `!unlayered` - (or `initial` or `*` or…) some name for the 'un-layered layer' so that it can be placed in the layer order like any other layer.
> 2. `!<layer-name>` - (or `up/down` or the slash proposal or…) some way of specifying if a layer belongs above or below unlayered styles.
> 3. `!overrides` - (or `!important` or `!top` or…) a pre-defined and permanently positioned layer that can't be moved, but can be added to.

A 4th option would be a new at-rule keyword to indicate that the added layers are “strong  layers”. These strong layers stack on top of unlayered styles.

We could do something like `@slayer` but I’m quite sure a certain Trash Metal band won’t like that. A syntax I like – and which I [mentioned it in the discussions about strong/weak scoping before](https://github.com/w3c/csswg-drafts/issues/6790#issuecomment-1470929341) is `@layer!`. It exclaims that the layers you are adding are strong layers and stack on top of each other _after_ the unlayered styles.

```css
@layer reset, base;
@layer! components, overrides;
```

The resulting stack – from low to high – becomes `reset, base, (unlayered), components, overrides`.

Advantage of this new at-rule keyword is that authors can feature detect it (`@supports at-rule(@layer!)`). It also prevents later rules from trying (and failing) to reposition the unlayered styles: as an author you don’t directly reposition the unlayered styles inside the layered ones, instead you put the unlayered ones before or after the unlayered ones.

-- 
GitHub Notification of comment by bramus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6323#issuecomment-2208577826 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 4 July 2024 09:53:55 UTC