- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Dec 2020 22:02:03 +0000
- To: public-css-archive@w3.org
Allowing a relative selector is technically doable, syntactically. However, it makes for a more complex line between valid and invalid syntax - you *can* write a selector without using `&` *if* you're chaining off of it with anything other than a descendant combinator. In Sass and other languages, this is more consistent, since it defaults to chaining off the parent with a descendant combinator. However, the final example *is* still syntactically ambiguous, because `&` can appear anywhere in the selector, and can appear multiple times. Is `.foo .bar:not(&)` meant to be descending from the parent as well, and thus actually equal to `& .foo .bar:not(&)`? Or is it a standalone selector, and the sole explicit `&` is *intended* to be the only parent reference? Both are valid and potentially reasonable. You can come up with heuristics for this, but they won't catch every valid case, and they make the syntax even *more* complex. All together, these changes would make the syntax slightly more complicated, won't reach the goal of "act like Sass" due to the inability to do relative descendant combinators, and save authors precisely two characters (or in some cases, depending on how they write them, *one*). -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5746#issuecomment-739046844 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 4 December 2020 22:02:05 UTC