6 ms·
Option 3 seems the most intuitive, but I can see the arguments for 5. It's 4 that I'm having a hard time understanding why anyone would want it that way. It's t
by LordDragonfang 4y ago
Option 3 seems the most intuitive, but I can see the arguments for 5. It's 4 that I'm having a hard time understanding why anyone would want it that way. It's truly awful. I can't think of literally any other language (style, markup, programming, or otherwise) that does nesting with a second set of adjacent (not nested!) curly braces.
- derkades 4y agoLaTeX maybe? But yes, I agree that it's awful.
- halostatue 4y agoSame. I think that the only thing I don’t like about 3 is the need for `:is(aside)` and the like, and I can see that there might be some performance benefit to `@nest {…}` blocks (5). I think the only thing I don’t like about 5 is the required `& {}` block. I find 5 to be the most consistent and 3 to be mostly cleaner because of what becomes optional.
- ezrast 4y agoI find 5 least consistent because there are now two competing ways to define an unnested block: the normal way, and the `@nest { & { ... } }` way. Why would anyone do the second way, you ask? Because that rule used to have a nested rule, and when it was taken out the programmer was lazy or didn't notice that it was the last nested case. Having to completely reformat the base rule just to add or remove a nested case is a complete deal breaker for me. I started liking option 4 when I started thinking of `} {` as a special "nested stuff here" sequence instead of a set of scope delimiters. True, it would be better if they had used basically any other sequence of bytes for that, but it still bothers me less then that goofy `:is()` requirement.
- TrianguloY 4y agoI voted for 4. For me it's the best option with }{ on a separate line. html { }{ & body { width: 100%; } } You have a clear distinction between the "standar" rules for the current object and then a different set of rules for nested ones. While reading css, on the other options you can mix both styles which (specially with the optional & ) can become easy to misunderstand.