I agree that it's not really worth it, but the answer is not to choose a worse option. The answer is the just not implement it.

These options are bad, and CSS does not need this.

> These options are bad, and CSS does not need this.

1. You don't have to use it if it doesn't seem useful to you.

2. Many developers (me included) use Sass and other preprocessors so they can use nesting; it's probably the single most popular feature of Sass.

3. CSS doesn't need nesting but a lot of developers want it, as it improves the developer experience for writing complex selectors.

> 1. You don't have to use it if it doesn't seem useful to you.

Other people will use it and chances are you will have to deal with it sooner or later at $dayjob or whatnot.

The group in 3 can use SASS. At this point you should view CSS like assembly, convenience functions go at a higher level.

> At this point you should view CSS like assembly, convenience functions go at a higher level.

CSS isn't assembly; it's higher level than that. I get why some want to treat it like a low-level language but it's not that, which is pretty obvious if developers take the time to understand CSS at a deeper level than just something a preprocessor spits out.

Also, CSS has to work in environments where using a preprocessor isn't an option—it's not just for glossy VC-backed websites. A preprocessor and all of the other tooling front-end developers use aren't an option for the vast majority of content management systems and wikis for example.

CSS still has to work in these environments.

I hope web standards decisions are never made starting from the assumption that there's a build tool.

I think the reason this debate continues to rage on is that all of the options are worse than what is currently available with pre-processors.

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.

> Nesting is not a requirement for CSS.

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 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.

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 was sad to see it left out of 2022-interop, but it's definitely the biggest feature I'm waiting for

My understanding is the features for Interop were chosen because there wasn't good interoperability between browsers for them.

With CSS Nesting, once the spec (and the syntax) is finalized, it's going to work the same in all browser engines; hopefully it'll go smoothly and we won't need CSS Nesting be part of Interop 2023.

Correct. I meant the "2022 Investigation" section of it which accounts for 10% of the grade and focuses on future features

I wouldn't disagree. Nesting state and pseudo selectors can clean up code.

20 bytes per rule. While not a fan of the syntax[1], there’s the advantage when reading of seeing that rules are explicitly nested versus doing string parsing of rule definitions.

[1] In particular the significant space char difference between &. And & .

Why does a website need more than one :hover rule?

At minimum, you'll likely have different effects for links than for buttons.

Component-centered design is very common so the styles for each component that would benefit from :hover may have its own variation on it, for the color differences if nothing else.

:hover is not the only interaction pseudo-class, :focus and :active can also be nested.

Every pseudo class * everything that needs that pseudo class * time taken to write/reason/check each one

> I've stopped using preprocessor for years now.

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.

The biggest feature I miss from Sass is the indented syntax (though SugarSS does that better since it has multiline support); for now I make due even if semicolons and brackets add noise. There's still a use case for Sass if you need to build a CSS library and the loops and stuff is useful, but for general, contemporary CSS authoring, wanting to reach for loops and these extra features is a sign of a smell more so than not.

> The biggest feature I miss from Sass is the indented syntax (though SugarSS does that better since it has multiline support); for now I make do even if semicolons and brackets add noise.

Yes! The indented syntax is why I’ve stuck with Sass, Stylus and SugarSS for all these years for the same reasons you stated.

But… I decided it was worth going back to plain CSS due to CSS Nesting and to simply my tooling.

lightningcss is my new preferred tool for doing all the vilification and prefixing.

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 want to say this but too lazy to defend it.

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.

I paid happily. ~1hr of work for a tool I use all day every day. Support independent developers!