- From: Steinar H. Gunderson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Jan 2023 13:29:23 +0000
- To: public-css-archive@w3.org
> Changing it will allow both options to work, be more expressive, and easier to read naturally (for the simple fact `:is()` usage will be explicit). It will delay rollout, which would be a benefit in this scenario, as it means we won't end up with an afterthought of a solution tacked on later, that would likely add further confusion on what already will exist (authors are still playing catch-up on understanding `:is()` as it is). You are missing an important detail: Changing it will most likely make sure it isn't rolled out at all. Not delay it; stop it. It's unlikely we'll want to implement something that blows up into exponential memory use so easily and without warning, and if nothing else is acceptable to web developers, seemingly the only solution is to do nothing. > In both cases, we can live without nesting indefinitely, by using more verbose selectors and preprocessors, so there should be no impetus to push this forward in a state that doesn't fulfil what developers need from it. Yes, it sounds increasingly like we should just declare css-nesting-1 a painful learning experience, delete it permanently and go do something else. -- GitHub Notification of comment by sesse Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8310#issuecomment-1387077053 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 January 2023 13:29:24 UTC