I prefer Option 3, but IMHO the "&" should be required in all cases. Having it present in some places and absent in others makes the resulting code less readable, more ambiguous, and generally harder to understand. I'd rather keep things simple and uniform, even if it costs extra keystrokes.
Also: it would allow things like ".a { &.b { x: y; } }" (which would be equivalent to ".a.b { x: y; }") to be clearly differentiated from ".a { & .b { x: y; } }" (which would be equivalent to ".a .b { x: y; }"). Just ".a { .b { x: y; } }" looks ambiguous between the two, since it doesn't "look like" a descendant selector.
I don't think it needs to be required, but I'd 100% include that in any linter or style guide I had for code.
For production code, I'd use it 100% of the time. For just quickly reorganizing some syntax around and copy/pasting things, I appreciate the shorthand version. I wouldn't use it in a codepen in most situations.
I very strongly agree. Mandatory & makes things much clearer, for a negligible cost. (And really, the curly braces, colon and semicolon are all mandatory (well, except the last semicolon of a ruleset), and alternative syntaxes with less punctuation like Sass’s have failed; the & is frankly more consistent than its absence.)
For a more technical justification: with optional &, priority is given (by brevity) to the descendant combinator, but what of other combinators? Do they require & or not? It could reasonably go either way. I haven’t read recent proposals, but am very familiar with CSS grammar, and I’m genuinely unsure.
parent {
/* This might or might not work. */
> child {
…
}
}
parent {
& > child {
…
}
}
This is another good point, particularly because (IMHO) people tend to overuse the descendant combinator in places where they should really use the child combinator instead.
Optional and being able to require it with e.g. a linter on a per-project basis seems better idea for me, since I'd strongly prefer not using & and for the vast majority of cases (as we learned from SASS) it's not needed.
Q for Smarter people than me with more experience: is it better to require stricter upstream and loosen the downstream (so would require &, and MyCSS framework could insert them where needed) or looser upstream and tighten local code with linters?
"be conservative in what you do, be liberal in what you accept from others" applies?
I don't know, I have been using SASS/LESS for a while and I almost never use the & because 95% of the time, I am talking about a descendant when I use nesting. I think it would be very easy to accidentally typo or miss in a review the difference between "& .sub-class" and "&.sub-class."
I agree completely, and having followed this since it was a pipe dream, I’m actually sad that the machine parsing and unambiguous human readability convergence lasted so long to hold this up only to fall apart as it becomes a real possibility.
Not a requirement because it’s not in the spec or because developers don’t need it? If the former, the proposal is to make it a requirement. After CSS grid, CSS nesting is probably the most requested feature of CSS for as long as I can remember for web devs. I only use sass these days for nesting and it would be nice if I didn’t need that extra dependency.
I've stopped using preprocessor for years now. Almost everything I need is now in the spec or solved ‘good enough’ through a naming scheme. IMO, a preprocessor is a lot of complexity for little gain currently.
Eh. I kinda hate writing separate selectors just for a `:hover`
I agree CSS has come a long way. Nested CSS is the one thing I'm waiting for before I completely abandon preprocessors.
Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. Sure, better practices could usually make this unnecessary, but there's definitely valid situations for it. If you add up all the extra kb across millions of sites, and all the extra savings minifiers would be able to achieve with this syntax, I'd bet it starts to add up at a certain point
I was sad to see it left out of 2022-interop, but it's definitely the biggest feature I'm waiting for
I do wonder whether "no nesting" should've been an option in the poll. Not because I necessarily think it's the right option, but it might be: if this gets added to CSS, but people keep using other tools for easier nesting, then we're stuck with that implementation nonetheless.
I try not to use preprocessors or bundlers/build tools for simple stuff so the addition of features like this to the base CSS language is something I look forward to.
Preprocessors aren't always available though. For example, I almost never have access to one, developing with MediaWiki (there is an extension that makes it available but most of the wiki farms I've worked for have not had it installed).
> If CSS can’t match or improve on the obvious syntax used by sass then they should not implement it.
And this is the problem. For so long there was a technical limitation because parsing complexity, then there suddenly wasn’t a limitation anymore and the existing syntax wasn’t good enough anymore so we’re shooting the moon.
I agree, all of the options are confusing. The only seemingly viable option is close to Sass, but it should just be strict and stop introducing more ambiguity to the grammar which is already absurdly complex.
For sake, Stylus doesn't even require colons and semicolons with plenty more features that was invented more than a decade ago and CSS is still trying to sort out things that was solved in 2010 in worse ways in 2022?
This is beyond comprehensible.
I guess I can never let go of preprocessors.
> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work.
I wish browser vendors could work around this limitation and stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.
> I wish browser vendors could work around this limitation and stick to Sass syntax.
FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web will become ever so slightly slower. And you cannot ever go back after making that choice. Is it really worth it for the few unusual cases that require workarounds, in an already not-super-common feature?
(Disclaimer: I wrote Chromium's CSS nesting support. It currently implements option 3.)
Syntactically speaking these two lines are equivalent except for a single semicolon; the differing first token doesn't change anything about that. And you can absolutely add a custom element that looks like a property name to blur a line further. So in order to see if the first block is a rule or a property, you absolutely have to read up to the first `;`, excluding nested braces and alikes.
That said, the main problem is that the property syntax is overly forgiving, not that the nested rule syntax is problematic. Something akin to JS `use strict` should be able to restrict the property syntax enough to allow the nested rule syntax without unlimited lookahead.
Do you have any numbers on that? On a modern computer, I'm having trouble believing that the time difference would be noticeable to a human. Seems like parsing even a few megs of CSS would be measurable in milliseconds?
What happened to the rule where if the nested selector doesn’t start with & then an explicit @nest is required? Doesn’t that fix the unlimited look-ahead?
I don't really get how tbh. Isn't Option 3 the exact same thing as Sass except the "&" is required in a few more places than it is in Sass? It's also optional in Sass so I already write that way (always using the "&") personally
I'm a bit confused about the constant mention of option 3 in this article, because it seems to match none of the actual options from the original poll. The original poll offered three options:
Option 1: @nest. Requires either starting a nested selector with &, or prefixing it with @nest if the & should not be at the start.
Option 2: @nest restricted. Always requires starting with @nest.
Option 3: Additional brackets to group nested selectors.
The "option 3" mentioned in this article matches none of those. It's like option 3 without the defining characteristic of the brackets, or option 1 without the required nesting indicator (but now with the restriction that the selector needs to start with a symbol).
None of these options are particularly great. The new "option 3" looks cleanest, but the symbol requirement is going to trip people up.
Isn't this what Sass does? Option 3 seems to me to be exactly Sass nesting except the "&" is required in more places than it is in Sass. I personally love the "&" and already write my Sass that way anytime I nest
Wow. I’m really surprised so many people have voted for option 3 so far. Option 5 feels much more in line with the rest of the other proposals and features in CSS, and option 3 introduces at least one quirk we’ll have to internalize and teach to everyone forever. Those suck. I have to teach those kinds of things to juniors until my throat is sore some days.
I don’t have much of substance to say about option 4 other than that it just feels… gross. I’m sorry, but those butterfly brackets are really extra.
Circling back, I think my preference for option 5 is that I personally moved away from nesting with preprocessors after watching too many developers create specificity bombs in their CSS from selectors nested 4 or 5 layers deep. I think it makes sense for this syntax to have a clear, distinct weight to it. CSS should be meant to be read just like all other code.
Finally, and I won’t spend too much time on this because I’m not trying to be a detractor, I’m not sure this is really high up on my wishlist anymore. Component-based design has changed a lot about the way I write CSS. I’ve found that I write a lot fewer highly-specific selectors these days, and I never have to bother with heavy id/class syntax conventions like BEM anymore for things to be easy to understand either. Those two things alone were big, dangerous motivators for me to use or encounter nesting. Anyway, I voted for option 5.
The web has given me an amazing career and life (that I feel is still very much only getting started). I’m always happy to contribute when I can.
That being said, I wish I could better articulate my opposition to No. 4. I think it’s because it immediately strikes me as a typo, like if someone was editing some CSS, deleted a selector and then forgot to write a new one back in before committing their work. Others seem to suggest that formatting addresses this, but I’m uncomfortable with that because it’s very subjective.
Option 5 is more structured but Option 3 is faster for a person to work with. I don't think either approach is necessarily more "long term" than the other unless there is another tradeoff I'm missing neither is an invalid thing to optimize the long term for.
Having to go back and modify the existing non-nested lines when you just want to add a nested declaration seems like a large source of "oh damn it" errors and twiddling when you are progressively building/testing styling. The same with wanting to keep default and pseudo-class attributes close to each other for human convenience.
It’s a fair question. Almost anything can be a weapon if you try hard enough. “Prevent” is perhaps too strong a verb. I’d settle for discourage or maybe even just contextualize. I get the impression that by explicitly declaring each nesting context with “@nest”, the effort required to type those extra characters might center the meaning more around code organization, maybe? If nothing else, it helps the eye track better in deeper trees.
In my experience, when I’ve committed this sin or watched others do so, it’s often because some styles that have already been written need to be updated. Writing CSS is really easy. Nesting makes it even easier. The thing I and I think most people struggle with is organizing it. I think nested styles encourage people to go out in search of a defined scope to ammend moreso than it does to encourage them to write a new one (or selector). It’s easy to see a class you’d need, skip a couple levels down the tree and then get excited when you add just that one element or class you think you need and style accordingly… Only to find out later that you created a difficult to debug style bug that pervades the whole site. My hope is that it would encourage people to think twice before going beyond that second or third level and maybe encourage them to create a new style block instead. I’m also not terribly concerned length or effort these days because of tab completion.
Option 3 seems the most intuitive, but I can see the arguments for 5. It's 4 that I'm having a hard time understanding why anyone would want it that way. It's truly awful. I can't think of literally any other language (style, markup, programming, or otherwise) that does nesting with a second set of adjacent (not nested!) curly braces.
Same. I think that the only thing I don’t like about 3 is the need for `:is(aside)` and the like, and I can see that there might be some performance benefit to `@nest {…}` blocks (5). I think the only thing I don’t like about 5 is the required `& {}` block.
I find 5 to be the most consistent and 3 to be mostly cleaner because of what becomes optional.
I find 5 least consistent because there are now two competing ways to define an unnested block: the normal way, and the `@nest { & { ... } }` way. Why would anyone do the second way, you ask? Because that rule used to have a nested rule, and when it was taken out the programmer was lazy or didn't notice that it was the last nested case. Having to completely reformat the base rule just to add or remove a nested case is a complete deal breaker for me.
I started liking option 4 when I started thinking of `} {` as a special "nested stuff here" sequence instead of a set of scope delimiters. True, it would be better if they had used basically any other sequence of bytes for that, but it still bothers me less then that goofy `:is()` requirement.
I voted for 4. For me it's the best option with }{ on a separate line.
html {
}{
& body {
width: 100%;
}
}
You have a clear distinction between the "standar" rules for the current object and then a different set of rules for nested ones. While reading css, on the other options you can mix both styles which (specially with the optional & ) can become easy to misunderstand.
For me it's the opposite. I find the nesting far easier to parse, especially when deeply nested. One thing to consider is what the average dev uses - looking at the 2021 state of css ( https://2021.stateofcss.com/en-US/technologies/pre-post-proc... ), SASS was used by 90% of responders, and of those 84% of them were satisfied with it.
There's a strong argument to be made that nesting is the standard way to write CSS these days (at least among the demographic that responded).
that's great, but sometimes when I start vanilla side projects I like to take a CSS Zen Garden approach to things. That's harder to do the more tightly you couple your HTML and your CSS
One could be forgiven for thinking any committee depraved enough to enumerate the options sequentially as 5, 4, or 3, moreover where option 3 is not even the same as the prior option 3, has implicitly renounced any standing to be offering solutions in re. developer ergonomics.
Readit News
Also: it would allow things like ".a { &.b { x: y; } }" (which would be equivalent to ".a.b { x: y; }") to be clearly differentiated from ".a { & .b { x: y; } }" (which would be equivalent to ".a .b { x: y; }"). Just ".a { .b { x: y; } }" looks ambiguous between the two, since it doesn't "look like" a descendant selector.
For production code, I'd use it 100% of the time. For just quickly reorganizing some syntax around and copy/pasting things, I appreciate the shorthand version. I wouldn't use it in a codepen in most situations.
For a more technical justification: with optional &, priority is given (by brevity) to the descendant combinator, but what of other combinators? Do they require & or not? It could reasonably go either way. I haven’t read recent proposals, but am very familiar with CSS grammar, and I’m genuinely unsure.
"be conservative in what you do, be liberal in what you accept from others" applies?
So e.g.
instead of the more intuitive (but impossible)Deleted Comment
If CSS can’t match or improve on the obvious syntax used by sass then they should not implement it.
All of these options are confusing. Nesting is not a requirement for CSS. Just let it go and if you want nesting use sass.
Not a requirement because it’s not in the spec or because developers don’t need it? If the former, the proposal is to make it a requirement. After CSS grid, CSS nesting is probably the most requested feature of CSS for as long as I can remember for web devs. I only use sass these days for nesting and it would be nice if I didn’t need that extra dependency.
Same. I'm using plain CSS on my current project while using the test implementation of option 3, using PostCSS plugins.
BTW, there is a spec [1].
[1]: https://drafts.csswg.org/css-nesting/
I agree CSS has come a long way. Nested CSS is the one thing I'm waiting for before I completely abandon preprocessors.
Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. Sure, better practices could usually make this unnecessary, but there's definitely valid situations for it. If you add up all the extra kb across millions of sites, and all the extra savings minifiers would be able to achieve with this syntax, I'd bet it starts to add up at a certain point
I was sad to see it left out of 2022-interop, but it's definitely the biggest feature I'm waiting for
I decided to not use Sass on my latest project; feels like CSS is at the point where I didn't need it any more. CSS has come a long way.
And this is the problem. For so long there was a technical limitation because parsing complexity, then there suddenly wasn’t a limitation anymore and the existing syntax wasn’t good enough anymore so we’re shooting the moon.
I agree, all of the options are confusing. The only seemingly viable option is close to Sass, but it should just be strict and stop introducing more ambiguity to the grammar which is already absurdly complex.
This is beyond comprehensible. I guess I can never let go of preprocessors.
I wish browser vendors could work around this limitation and stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.
FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web will become ever so slightly slower. And you cannot ever go back after making that choice. Is it really worth it for the few unusual cases that require workarounds, in an already not-super-common feature?
(Disclaimer: I wrote Chromium's CSS nesting support. It currently implements option 3.)
That said, the main problem is that the property syntax is overly forgiving, not that the nested rule syntax is problematic. Something akin to JS `use strict` should be able to restrict the property syntax enough to allow the nested rule syntax without unlimited lookahead.
These options are bad, and CSS does not need this.
That is my biggest take away from this whole thing. The SASS/LESS syntax is so much easier to read to me.
Option 1: @nest. Requires either starting a nested selector with &, or prefixing it with @nest if the & should not be at the start.
Option 2: @nest restricted. Always requires starting with @nest.
Option 3: Additional brackets to group nested selectors.
The "option 3" mentioned in this article matches none of those. It's like option 3 without the defining characteristic of the brackets, or option 1 without the required nesting indicator (but now with the restriction that the selector needs to start with a symbol).
None of these options are particularly great. The new "option 3" looks cleanest, but the symbol requirement is going to trip people up.
Isn't this what Sass does? Option 3 seems to me to be exactly Sass nesting except the "&" is required in more places than it is in Sass. I personally love the "&" and already write my Sass that way anytime I nest
Deleted Comment
Deleted Comment
I don’t have much of substance to say about option 4 other than that it just feels… gross. I’m sorry, but those butterfly brackets are really extra.
Circling back, I think my preference for option 5 is that I personally moved away from nesting with preprocessors after watching too many developers create specificity bombs in their CSS from selectors nested 4 or 5 layers deep. I think it makes sense for this syntax to have a clear, distinct weight to it. CSS should be meant to be read just like all other code.
Finally, and I won’t spend too much time on this because I’m not trying to be a detractor, I’m not sure this is really high up on my wishlist anymore. Component-based design has changed a lot about the way I write CSS. I’ve found that I write a lot fewer highly-specific selectors these days, and I never have to bother with heavy id/class syntax conventions like BEM anymore for things to be easy to understand either. Those two things alone were big, dangerous motivators for me to use or encounter nesting. Anyway, I voted for option 5.
No. 3 is the knee jerk, in the heat of the moment response; but no. 5 makes the most sense long term.
That being said, I wish I could better articulate my opposition to No. 4. I think it’s because it immediately strikes me as a typo, like if someone was editing some CSS, deleted a selector and then forgot to write a new one back in before committing their work. Others seem to suggest that formatting addresses this, but I’m uncomfortable with that because it’s very subjective.
Having to go back and modify the existing non-nested lines when you just want to add a nested declaration seems like a large source of "oh damn it" errors and twiddling when you are progressively building/testing styling. The same with wanting to keep default and pseudo-class attributes close to each other for human convenience.
In my experience, when I’ve committed this sin or watched others do so, it’s often because some styles that have already been written need to be updated. Writing CSS is really easy. Nesting makes it even easier. The thing I and I think most people struggle with is organizing it. I think nested styles encourage people to go out in search of a defined scope to ammend moreso than it does to encourage them to write a new one (or selector). It’s easy to see a class you’d need, skip a couple levels down the tree and then get excited when you add just that one element or class you think you need and style accordingly… Only to find out later that you created a difficult to debug style bug that pervades the whole site. My hope is that it would encourage people to think twice before going beyond that second or third level and maybe encourage them to create a new style block instead. I’m also not terribly concerned length or effort these days because of tab completion.
I find 5 to be the most consistent and 3 to be mostly cleaner because of what becomes optional.
I started liking option 4 when I started thinking of `} {` as a special "nested stuff here" sequence instead of a set of scope delimiters. True, it would be better if they had used basically any other sequence of bytes for that, but it still bothers me less then that goofy `:is()` requirement.
I find all the examples harder to read and understand than combining classes/elements.
There's a strong argument to be made that nesting is the standard way to write CSS these days (at least among the demographic that responded).
Come back, DSSSL, all is forgiven.