Re: [csswg-drafts] [css-cascade] [css-nesting] Figure out whether we're fine with "shifting up" bare declarations after rules (#8738)

I don't understand why you think it's acceptable to magically _add_ `@nest`, but not magically _remove_ it. They seem like two sides of the same coin to me, and if anything doing one without the other is inconsistent. Having `@nest` magically appear in my code when I try to roundtrip it seems way weirder than seeing a manually authored `@nest` disappear in the same case. And it's still unclear to me what is the value of allowing authors to write `@nest` at all. If there is none, then the case of an author writing `@nest` and seeing it disappear if they try to roundtrip will be _exceedingly_ rare. 

> Importantly, pay attention to the use-case you're talking about - when does an author serialize a CSS rule and manually examine the results? 

I believe certain types of dev tools do this to at least some degree.

> There's a minimum amount of magic we need for usability's sake (automatically wrapping the declaration in this new rule when parsing), but beyond that I strongly prefer for everything to be as normal and unsurprising as possible. 

Are you saying that the expected frequency with which something is encountered doesn't factor in the API design choices you make? 

> Every bit of magic is another sharp corner we have to be aware of and design around, forever, vs something predictable and boring.

Wait, I thought we were talking about author ergonomics, when did it become about our convenience? 



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


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

Received on Tuesday, 16 April 2024 22:46:44 UTC