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

The CSS Working Group just discussed `Allow authors to explicitly place unlayered styles in the cascade layer order`, and agreed to the following:

* `RESOLVED: Reserve the CSS wide-keywords (making the whole layer block invalid at parse time) for now and details TBD when we have better use cases`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> topic: Allow authors to explicitly place unlayered styles in the cascade layer order<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/6323<br>
&lt;emilio> miriam: this one is another coming from an earlier resolution<br>
&lt;emilio> ... we resolved that unlayered styles are lower pri<br>
&lt;jfkthame> present-<br>
&lt;emilio> ... jen asked about whether it'd be useful to tweak the unlayered styles priority<br>
&lt;emilio> ... there's some syntax proposals in the issue<br>
&lt;Rossen_> q?<br>
&lt;emilio> ... and I'd expect it to work at each level of layering<br>
&lt;emilio> ... are we happy with an empty layer rule syntax? Does this become too complex?<br>
&lt;emilio> florian: I could see use cases for top/bottom, has any non-theoretical use case come up for in the middle?<br>
&lt;emilio> miriam: yeah, you want components at the top and resets on the bottom, so you might want most of your styles between them<br>
&lt;emilio> TabAtkins: Like florian I see the use case but I'm not sure we need to solve it right now<br>
&lt;emilio> ... we could resolve the CSS wide keywords as layer names in case we want to solve them<br>
&lt;emilio> miriam: does that become a problem if additional wide-keywords are added?<br>
&lt;Rossen_> ack fantasai<br>
&lt;emilio> TabAtkins: theoretically? But we haven't added many over the years<br>
&lt;TabAtkins> s/resolve/reserve/<br>
&lt;emilio> fantasai: we could also do something that isn't a keyword<br>
&lt;emilio> ... I don't have strong opinion on having to solve this now, and I'd be ok reserving the wide-keywords<br>
&lt;fantasai> s/keyword/keyword, like an asterisk/<br>
&lt;emilio> florian: maybe I need to re-read the minutes for when we decided to switch top/bottom, I wasn't there and it seems !important could take care of jumping to the top<br>
&lt;emilio> miriam: main reason for that was that putting them at the bottom allows progressive enhancement<br>
&lt;emilio> ... sort of like when not all browsers had media queries you'd write the specific styles in there<br>
&lt;emilio> ... but lots of people think of layers as a way to hide their resets<br>
&lt;emilio> florian: I guess I see it more like the later but that also doesn't give me a strong use case for having unlayered styles in the middle<br>
&lt;emilio> ... I'd be fine reserving the wide keywords though<br>
&lt;emilio> fantasai: so there's the question of whether we add it now, if we don't we might want to just reserve the keywords<br>
&lt;emilio> miriam: if we're not sure if it's needed I'd be ok with reserving the keywords and delaying<br>
&lt;emilio> ... since it adds a fair amount of complexity<br>
&lt;emilio> florian: what do we need by reserving the keyword? Just making them syntactically invalid?<br>
&lt;emilio> fantasai: yeah, if you define @layer with that keyword the whole block is in invalid<br>
&lt;emilio> florian: is that progressively-enhanceable? If you add a layer that doesn't work and then it starts working...<br>
&lt;emilio> fantasai: why would you type it in if it doesn't work?<br>
&lt;emilio> florian: would it be wholly invalid or just ignored?<br>
&lt;emilio> TabAtkins: could we bring that detail back to the thread?<br>
&lt;emilio> Emilio: fwiw it seems simpler to make the whole block invalid at parse time<br>
&lt;emilio> RESOLVED: Reserve the CSS wide-keywords (making the whole layer block invalid at parse time) for now and details TBD when we have better use cases<br>
</details>


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


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

Received on Tuesday, 27 July 2021 16:39:00 UTC