61–70 of 170 posts
Do we really need this? I find all the examples harder to read and understand than combining classes/elements.
Nesting is a solution in search of a problem. Combining classes has worked fantastically for me over the last 15 years.
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 t…
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 t…
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.
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.
Come back, DSSSL, all is forgiven.
parent {
...parent rules...
} @nest {
...nested rules...
}
An improved option 3 would be to unconditionally require the &.
Another alternative would be to stick with Sass syntax but require nested selectors to use :where:
parent {
...parent rules...
:where(child:pseudo) {
...nested rules...
}
}
parent {
...parent rules...
:nest(child:pseudo) {
...nested rules...
}
}
I'm not familiar with the past discussion of any of this, though.
I prefer Option 3, but IMHO the "&" should be required in all cases. Having it present in some places and absent in others makes the resulting code less readable, more ambiguous, and generally harder to understand. I'd rather keep things simple and uniform, even if it costs extra keystrokes. Also: it would allow things like ".a { &.b { x: y; } }" (which would be equivalent to ".a.b { x: y; }") to be clearly different…
I very strongly agree. Mandatory & makes things much clearer, for a negligible cost. (And really, the curly braces, colon and semicolon are all mandatory (well, except the last semicolon of a ruleset), and alternative syntaxes with less punctuation like Sass’s have failed; the & is frankly more consistent than its absence.) For a more technical justification: with optional &, priority is given (by brevity) to the des…
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.
Same. I'm using plain CSS on my current project while using the test implementation of option 3, using PostCSS plugins.
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.
BTW, there is a spec [1].
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 t…
genuinely curious, how does option 5 prevent specificity bombs?
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.
Earlier quoted context omitted.
> I wish browser vendors could work around this limitation and stick to Sass syntax. FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web w…
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.
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.