21–30 of 170 posts
It's very explicit whereas sass is implicit and harder to understand at a glance when nesting happens, especially when you throw in an & and have styles above and below the nested parts.
All these options are pretty terrible yeah. I'd prefer if there was work done towards selectors for parent items, siblings of parents, and children of parent siblings. Not that the work is mutually exclusive.
1. That's not one of the options.
2. Apple shipped the parent selector [1] in March and Google shipped it in August.
Do we really need this? I find all the examples harder to read and understand than combining classes/elements.
We want it to work the way Sass works. FFS make it happen and stop it with all this pedantry.
Did you read the third paragraph in the article?
It says: "If they see a sequence like element:pseudo, they’ll parse the entire style rule as if it were a property: value declaration.", but why can't the parser be modified to work like Sass parser?
Maybe it's obvious for someone who has deep parser knowledge, but for someone who only has a superficial knowledge, this is not clear. If Sass can transform .sass into .css, what's stopping Chrome from embedding the full sass software and preprocessing all css files with it, *if really wanted too*? While not ideal for obvious reasons, what I mean is: it seems to definitely be possible to do. Does this all just boil down to "we don't want to have the work of rewritting the CSS parser"?
Option 1: @nest. Requires either starting a nested selector with &, or prefixing it with @nest if the & should not be at the start.
Option 2: @nest restricted. Always requires starting with @nest.
Option 3: Additional brackets to group nested selectors.
The "option 3" mentioned in this article matches none of those. It's like option 3 without the defining characteristic of the brackets, or option 1 without the required nesting indicator (but now with the restriction that the selector needs to start with a symbol).
None of these options are particularly great. The new "option 3" looks cleanest, but the symbol requirement is going to trip people up.
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.
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.
html {
}{
& body {
width: 100%;
}
}
I know this is why we have shadow dom, but in practice I feel like the shadow dom has caused more problems than it solved.
Now we have a bunch of ::part things being added to make up for the problems, but it's still very difficult to work with.
I'd love to have the ability to put a tag inside a div and have it's rules only apply to the contents of that div, optionally overriding parent styles.
I don't know about the challenges implementing that in the engines, but it seems like it would be straightforward since the functionality already exists, style tags are valid markup almost everywhere in the dom, they're just parsed out and combined. For this you'd just have to track the parent element and bind to it like an ID selector.
This would make web component authoring more pleasant.
Edit: it looks like the functionality I'm asking for has already been considered, partially implemented, and is now deprecated, sadly.
Quite a few comments here aren't happy with any of them.