- From: Ian Harris via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Jul 2022 13:01:26 +0000
- To: public-css-archive@w3.org
harrisi has just created a new issue for https://github.com/w3c/csswg-drafts: == `[css-nesting]` `let rec` as an idea for infix decorator-style nesting syntax == Spec: https://www.w3.org/TR/css-nesting-1/ I'm reminded of OCaml's `let rec` which I'm somewhat surprised to not see any mention of, neither here (https://news.ycombinator.com/item?id=32248419) nor the GitHub issues. I was originally thinking of only treating nesting from a parent to child but the child to parent relationship does complicate things (especially since it seems much more likely with CSS to need to modify a parent - assigned from a library or framework, presumably - than typical imperative or functional programming). I originally thought a decorator-type syntax where "this definition includes nested elements" would be reasonable, since any user agent or linter or whatever could be in its rights (depending on spec) to look ahead a certain distance. Obviously this wouldn't actually be too reasonable with arbitrarily distant children. Anyway, I also initially thought I preferred the brackets since it's explicit and some of the best wording is odd to me, but I think after considering my own `let rec` idea I prefer the optional `@nest` syntax because the only odd case which is relevant - and often enough that succinct but obvious syntax is warranted - is the child->parent->* case. That's the only time I'd want a heads up while visibly parsing css. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7540 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 July 2022 13:01:31 UTC