- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Oct 2022 20:37:57 +0000
- To: public-css-archive@w3.org
They're separate just because all the at-rules have a dedicated type, and it seemed odd for @nest to be the one exception. Dropping it and just using CSSStyleRule is definitely possible, however. The big issue is just that you wouldn't preserve whether a style rule was written with @nest or not (unless we add some additional state to CSSStyleRule), so a rule like `@nest & > .foo {...}` would probably serialize down to just `& > .foo {...}`. (I think that's fine, fwiw.) > (Also, CSSRuleList does not support containing CSSNestingRule? Wouldn't it need to?) What do you mean by that? It's a list of CSSRule objects with no further checking performed, and CSSNestingRule is a CSSRule subclass. > In the same vein, there is something that appears to be slightly underspecified: The algorithm for CSSNestingRule's selectorText setter only specifies “if the algorithm returns a non-null value”, but it doesn't explicitly write anywhere that all selectors need to be nest-containing. This makes it potentially possible to write a non-nest-containing nested rule using CSSOM. Yup, that's a bug. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7831#issuecomment-1268947949 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 October 2022 20:37:59 UTC