Help Choose The Syntax For CSS Nesting

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.

Direct Link →

Comments

Berwyn Powell

# December 21, 2022

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.

Gust van de Wal

# December 21, 2022

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 the a:b problem 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.

Geoff Graham

Permalink to comment# December 21, 2022

I think the intent is less about developers deciding and more about what Jen says at the end:

There’s a lot that goes into designing a programming language, not just the results of a survey like this. But knowing what web developers think after reading examples will help us with our ongoing discussions.

Andy

# December 22, 2022

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.

Joy

# December 22, 2022

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.

# December 23, 2022

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.

Geoff Graham

Permalink to comment# December 23, 2022

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.

jma

# December 27, 2022

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.

@nest imo 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.

Cinnfhaelidh

# January 3, 2023

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:

.foo {}{
  & {
    color: red;
  }

  .bar {
    color: blue;
  }

  p {
    color: yellow;
  }
}

This also works well:

.foo {
  color: red;
  }{

  .bar {
    color: blue;
  }

  p {
    color: yellow;
  }
}

Comments

Leave a Reply Cancel reply