CSS Nesting is making the rounds yet again. Remember earlier this year when Adam and Miriam put three syntax options up for a vote? Those results were tallied and it wasn’t even even close.
Now there’s another chance to speak into the future of nesting, this time over at the WebKit blog. The results from the Adam and Miriam’s survey sparked further discussion and two more ideas were added to the mix. This new survey lets you choose from all five options.
Jen Simmons has put together a thorough outline of those options, including a refresher on nesting, details on how we arrived at the five options, and tons of examples that show the options in various use cases. Let’s return the favor of all the hard work that’s being done here by taking this quick one-question survey.
I just tried voting, but can’t see any way to do so, just the results so far. Perhaps it’s been closed? Doesn’t seem like very long to keep the poll open though.
It’s a shame, as I would have gone for option #5, which is currently not the favourite. I like the simplicity of #3 and its similarity to SASS, but the potential for weird bugs and edge cases makes me a little nervous. This is about choosing what’s right for the future of CSS after all.
Option #4 just makes my brain hurt, so I’m glad that’s not the favourite at least.
I see Jen mention the three original options (1, 2 and 3), the third of which was “enclosing nesting statements in brackets”. I don’t see that option being used in this article. What’s up with that? Am I missing something?
I do not believe developers should decide on these things, by the way. And yes, I believe that because of the current winner, option 3. The syntax forces you to use
:is()sometimes, which imo is as unrefined as you can get and honestly a total disgrace to the language. Elegance had been thrown out the window, whereas thea:bproblem could be solved by looking at what comes after — a semicolon (it’s a rule) or a bracket (it’s a selector and we’re nesting).But maybe that’s my naivety talking, I haven’t taken part in these discussion before and maybe I’m missing a detail in my example as well.
I think the intent is less about developers deciding and more about what Jen says at the end:
I dont understand why they say: In many of the following examples, the & is optional.
There is no example with “.foo.bar”.
But Option #3 is ok – i think.
I also couldn’t see a way to vote.
If I could, I would vote to not have nested CSS at all. Every example is easier to read and copy and debug using the unnested CSS. I say leave the nesting stuff to pre or post processors, so that it’s optional.
I don’t understand why this even had to be put up for a vote. Just use the same nesting style as less and sass have been doing for years – it’s what frontenders already know and expect.
I’m glad regular @nest won.
You might wanna give Jen’s post a closer read because it covers why we’re unable to use the same syntax as Sass or Less.
What baffles me the most is why do people choose a syntax that is literally the same to SASS, like if you’re going to choose that then just use the preprocessor.
@nestimo feels much more consistent to the css syntax, or maybe just dont introduce any nesting at all.CSS doesn’t need to follow the preprocessor’s footsteps, and instead should just focus on improving in features that are out of their control.
I don’t understand why option 4 got the fewest votes. It’s much cleaner than option 5 and doesn’t have the issues that the winning option has with not allowing a letter as the first character of a selector (that :is() workaround is hardly elegant).
I especially like this:
This also works well: