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.