Comment by CSSer | Hacker News Reader

Comment by CSSer | Hacker News Reader

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.

Thanks for the thoughtful response.

No. 3 is the knee jerk, in the heat of the moment response; but no. 5 makes the most sense long term.

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.

>Others seem to suggest that formatting addresses this,

I feel the same way about python. To me, indentations and spaces are much more for human legibility than the parser's. Something in my brain says that symbols like curly/square braces designate code blocks much more succinctly than white spaces.

However, for someone that started in a language that used white spaces vs symbols, I get how they would feel the opposite.

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.

genuinely curious, how does option 5 prevent specificity bombs?

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.

Reply on news.ycombinator.com