13 ms·

Help pick a syntax for CSS nesting

217 points by feross 4y ago

lioeters 4y ago
I was hoping the new CSS syntax for nesting would work just like in Sass, simple and intuitive. Unfortunately, it's apparently too ambiguous and inefficient for parsing. > Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration.. > It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. > CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS. https://drafts.csswg.org/css-nesting/#nesting https://drafts.csswg.org/css-nesting/#nesting
somishere 4y ago
Implicit @nest every time for me .. except for example 8 where brackets (finally) made some sense. Also intrigued by the example 9 `&[open]` edge case. Wild. Honestly tho, I think scss has it right where ampersand is only used for grouping / parenting.
Etheryte 4y ago
Perhaps I simply don't see the ambiguity after having used Scss, Less and the like for a long time, but isn't the simple `&` by far the best option here? The other two are absurdly verbose without offering any real benefit.
- esteth 4y ago
  The simple '&' requires infinite lookahead to parse.
  - aasasd 4y ago
    Afaict the lookahead problem refers not to the proposals, but to a syntax without these extra markers altogether. Which is why all the proposals have some markers.
  - jimmaswell 4y ago
    So what? That's a complete non-problem.
  - jeshin 4y ago
    no it doesn't, the simple no-prefix solution requires infinite lookahead
donatj 4y ago
All of these are stupid. Why can’t we just have the scss syntax? It’s already proven.
- mrcartmeneses 4y ago
  100% agree. The community has already chosen the syntax it wants by voting with its feet for SCSS
  - esteth 4y ago
    Except that syntax requires infinite lookahead to parse. It's feasible when you're running a preprocessor on your own code one time, but not feasible for the browser to do on unknown code on every stylesheet it encounters.
    - bornfreddy 4y ago
      I'm quite sure some edge cases could be forbidden to speed ip parsing. The most common use in my experience is simple nesting ("& .child"), and I would argue other forms should be avoided for readability reasons anyway. But finding 3 other solutions (because of "performance"), not promoting them through transpiling, and then forcing them on web devs seems... googley. Not the first improvement they forced down our throats and unfortunately not the last. /rant
    - marcosdumay 4y ago
      You can just bound the lookahead on the browser by some large number, and accept smaller performance loses for parsing. Anyway, if your possibilities are only nested selector and property, why don't you compute both until they are not ambiguous anymore? You don't need backtracking.
  - myfonj 4y ago
    Jake Archibald points out [1] section [2] in that page that explains it somehow. Haven't grokked it yet, but I see that popular SASS (SCSS)-BEM way of doing .block { &__element { &--modifier { p: v; } } } for getting .block__element--modifier { p: v; } could really be problematic from CSS parser perspective. Also in SASS `&` really is kinda placeholder and I think you can do stuff like .x { &+&+& { p:v; } } to get .x + .x + .x { p: v; } what again seems problematic. (But again, I don't say I've grasped that fully.) [1] https://twitter.com/jaffathecake/status/1552200992179077126 https://twitter.com/jaffathecake/status/1552200992179077126 [2] https://developer.chrome.com/blog/help-css-nesting/#:~:text=Why%20can%27t%20the%20exact%20nesting%20example%20shown%20above%20be%20the%20syntax%20for%20CSS%20nesting%3F https://developer.chrome.com/blog/help-css-nesting/#:~:text=...
di4na 4y ago
None of them honestly. All of them are atrocious to type and parse for a human. The option 1 is probably the best but urgh
- emn13 4y ago
  I think option 1 is the worst, because it's not actually optional; it's required precisely when css selectors become complex. That the kind of gotcha that just makes everything harder to explain and read. I hope the proposal fails entirely, and that no nesting syntax is adopted. It's not worth it, and nesting in SCSS is abused more often than not anyhow. There are a few exceptions like pseudo-elements and media queries that are always harmless, but most nesting is just asking for specificity gotchas later, or component refactoring surprises.
richthegeek 4y ago
Looks like another round of W3C bike-shedding an existing easy-to-use and well-understood community standard until it's godawful to work with and half as useful. Gotta love standards bodies!
- mrcartmeneses 4y ago
  - madeofpalk 4y ago
    This is just css. No one's going to die.
  - blowski 4y ago
    No, these are the kind of people who are deliberating on the best syntax to support millions of projects using CSS for the next 30 years. They have to factor in backwards compatibility, extensibility, performance, security, accessibility, responsiveness, and lots of other NFRs. Once it’s out there, it has to be supported for a long time. It’s worth deliberating to get right. Nobody will die because they took their time.
    - Aeolun 4y ago
      Kinda? People have been working with their preferred syntax for oh, the last 10 years or so? It’s scss. No point in making a poll with an answer that’s already decided.
      - blowski 4y ago
        They mention in the post this has issues because browsers don’t have a build step in the same way Sass has. What’s your solution for that?
        JoBrad 4y ago
        Support look ahead to some limit, then fail that css resource, with an error message that is more verbose in the dev console.
mrcartmeneses 4y ago
Just make it like scss. It’s what most people that use nesting in css already know and has been shown to work
singaporecode 4y ago
krajzeg 4y ago
These all feel like an overengineered solution in search of a problem, with some degree of tunnel vision in that all three proposals try to support the same broad set of capabilities. It looks like somebody decided that nesting support must somehow support "reverse nesting", eg. that you'd like to define what happens to .foo when it's inside a .bar, but nested inside the definition for .foo: .foo { .bar > .foo { ... } } Does anybody actually want this? It feels counter-intuitive and weird, and with the syntaxes proposed, seems to provides little benefit compared to just doing it as the old ".bar > .foo" without nesting. If you drop the requirement for nesting to work in reverse, you can just go with the proven SCSS syntax which is extremely clear, straightforward to use, and requires 0 extra characters typed. EDIT: Apparently the '&' or some other special token is required to prevent the need for unlimited lookahead while parsing. This is actually explained behind a folded caption in the article, which I initially missed.
- akdor1154 4y ago
  The @media application of this seems useful, but yeah arbitrary parents seems not a must-have.
  - krajzeg 4y ago
    Apparently, those already work differently than other selectors in the proposals (example 7): .foo { display: grid; @media (width => 30em) { grid-auto-flow: column; } } I would expect "@nest @media (width => 30em) & {" for consistency with how it works everywhere else, but apparently @media is already special anyway in the "@nest" proposal. I agree that this syntax could be convenient, though I'm actually a fan of having all the "@media" changes in one place, which is what the current syntax forces.
- somishere 4y ago
  Apologies if I misunderstand, but your "reverse nesting" syntax already works with scss. I.e. `.a{ .b & {}}` => `.b .a {}` ... I'd quite honestly use it fairly often, usually with state/data modifiers on an ancestor (or ancestor sibling!)
pointlessone 4y ago
I see that many didn't read the hidden part of the post that explains why SCSS version can not be used. Here's the relevant excerpt. > ## Why can’t everything be directly nested? > Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration, so an implementation requires unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule. > For example, if a parser starts by seeing color:hover ..., it can’t tell whether that’s the color property (being set to an invalid value...) or a selector for a <color> element. It can’t even rely on looking for valid properties to tell the difference; this would cause parsing to depend on which properties the implementation supported, and could change over time. > Requiring directly-nested style rules to use nest-prefixed selectors works around this problem—an & can never be part of a declaration, so the parser can immediately tell it’s going to be parsing a selector, and thus a nested style rule. > Some non-browser implementations of nested rules do not impose this requirement. It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS.
- krajzeg 4y ago
  Thanks for pointing this out, I indeed missed that (it's hidden behind a folded caption). It still doesn't explain why all the proposals feel the need to be more powerful than SCSS nesting (allowing "reverse nested" definitions where the element being nested in is not at the start), but it does explain the need for "&". EDIT: Actually, it looks like SCSS supports the same thing by using '&' anywhere in the definition. I'll just stop posting since it looks like my knowledge is too rusty to contribute positively.
  - Semaphor 4y ago
    I’m not sure if I understand you correctly, but I think SCSS does actually support that. dialog { html:has(&[open]) { overflow: hidden; } } Is possible annd creates html:has(dialog[open]) {overflow: hidden;}
lovasoa 4y ago
So now we discuss web standards on chrome.com ? This looks like the beginning of the end of a free web governed standards established by an independent body. I would have expected such an article to be published on w3.org...
- mattgperry 4y ago
  Why didn't they publish one then?
- oefrha 4y ago
  Any person can publish a blog post discussing web standards on the “free web”. You’re welcome to publish one yourself.
  - echelon 4y ago
    Too many Google engineers working on this to keep up.
- tannhaeuser 4y ago
  It also looks like asking the general public for a go to make CSS even more complicated, when we all know it's a one-way ticket to Chrome dominance, ie a rhetoric dictators have been using. Note the absence of the option to "do nothing" and keep good-damn CSS as it is already after 25+ years of tinkering that haven't solved its problems. I mean even one of the long-term editors of the CSS spec has raised hands and warned against including ever more inessential and author-oriented features [1]. That was almost 14 years ago. [1]: https://www.w3.org/People/Bos/CSS-variables https://www.w3.org/People/Bos/CSS-variables
  - aasasd 4y ago
    > That was almost 14 years ago. Now that's a page that can be dated by its look.
    - noSyncCloud 4y ago
Zoadian 4y ago
can we just get native styl support into the browser please
saagarjha 4y ago
IMO this is one of the things, like TypeScript, where transpiling before hitting the browser is good enough considering the downsides of baking this into three web engines.
toastal 4y ago
Folks undervalue how much `:is()` and `:where()` can eliminate nesting and works in most browsers right now.
wwalexander 4y ago
> determining which should be championed through to a specification candidate Didn’t they mean “implemented in Chrome and therefore forced into the CSS standard due to browser monoculture”?
- jaffathecake 4y ago
  No. This research is ahead of a CSS working group meeting, where its inclusion into the standard will be discussed.
cphoover 4y ago
I really don't find nesting to be a necessary part of the CSS spec and in fact find deeply nested CSS rules harder to reason about.
LAC-Tech 4y ago
I'm glad this is happening. Languages that transpile to CSS require extra tooling and setup, and if there's one thing our web apps have too much of it's tooling and setup. I will be able to make much stronger cases to get rid of SASS, SCSS etc when this happens.
kazinator 4y ago
How about: x = .nesting { color: hotpink; } y = x > .is { color: rebeccapurple; } y > .awesome { color: deeppink; } plus: x = .nesting; y = x > .is; z = y > .awesome; x { color: hotpink; } y { color: rebeccapurple; } z { color: deeppink; } The names x, y and z aren't ambiguous because they are lexically defined. They could be allowed to shadow tags: pre = .foo > .bar; then from that point on, pre isn't the HTML tag, but the above definition. Or else tags could be reserved: cannot use those as names. (Causing trouble when new tags get introduced; bad idea.) Regarding the @nest syntax, why couldn't it look like an attribute? ...sel... { color: blue; nest: > .whatever { ... } } Or just the colon: ...sel... { color: blue; : > .whatever { ... } } Why use containment to express the nesting? What is being nested is the selectors. The braces group something else: the attributes affected by selectors. Why would nested selectors have to go into those braces? The + character at the start of a rule could mean "the selector of the previous rule": .nesting { color: hotpink } + > .is { color: rebeccapurple } + > .awesome { color: deeppink } Or use a master outer brace for this: { .nesting { color: hotpink } > .is { color: rebeccapurple } > .awesome { color: deeppink } } The understanding is that the rules grouped in the brace have a cumulative selector, rather than independent selectors. Or what if braces just group, and @nest (or whatever) is required to indicate the selector stacking semantics: @stack { .nesting { color: hotpink; } > .is { color: rebeccapurple; } > .awesome { color: deeppink; } } Now you can have N levels of selector refinement without N levels of syntactic containment. The containment is still available: @stack { .nesting { color: hotpink; } > .is { color: rebeccapurple; } { /* parallel rules: not a stack */ .awesome { color: deeppink; } .terrific { color: yellow; } } @stack { /* stack-in-stack, cross-producting. */ .even { color: red; } .more { color: green; } .nested { color: blue; } } } Here, because the nested @stack follows a block of parallel rules, a Cartesian product semantics can come into effect. That is to say, it is equivalent to: @stack { .nesting { color: hotpink; } > .is { color: rebeccapurple; } { @stack { .awesome { color: deeppink; } .even { color: red; } .more { color: green; } .nested { color: blue; } } @stack { .terrific { color: yellow; } .even { color: red; } .more { color: green; } .nested { color: blue; } } } } The @stack following a parallel rule causes the @stack to distribute into the parallel branches. Kind of like Bash brace expansion: $ echo nesting-is-{awesome,terrific}-even-more-nested nesting-is-awesome-even-more-nested nesting-is-terrific-even-more-nested
azangru 4y ago
I like the first option, with the ampersand. Having to write @nest looks yucky, and an extra pair of curlies is confusing.
Aeolun 4y ago
Honestly, if SCSS works, then I don’t see how they can say it’ll be a problem in the browser. It already works, lets not require everyone to redo everything they already have. Have the browser show a warning in the style of “An unbounded lookahead is making this page slow” when, and if it happens, and the site owner can do something about that crazy thing.
- its_bbq 4y ago
  Yes but the cost is paid once by the developer at compile time. I'm this case, the cost would be paid by every visitor on every page visit
  - Aeolun 4y ago
    That’s already true for all the Javascript tracking and ads. It seems silly to now worry about a few extra ms that it takes the CSS parser to resolve it’s difficulties. Maybe if they specified how long this ‘infinite’ lookahead takes in all their scenarios, it would be more compelling.
    - its_bbq 4y ago
      Tracking and ads scripts aren't special here. Yes page rendering is paid by the browser every time, and this group of people is specifically worried about the CSS part of that process. They're separate concerns and don't need to influence each other design wise
      - seba_dos1 4y ago
        Also, CSS is often used in other contexts than web browsing as well.
        its_bbq 4y ago
        Really? I'm not aware of any except exports of the browser stack like Electron.
meerita 4y ago
I learned a long time ago that this kind of approach only brings problems in the long run: you end up building house of cards all the time. All our problems went away when we adopted functional CSS.
aasasd 4y ago
Choosing only among the given proposals, what I see is one clear, concise and reasonably elegant syntax, and two ugly and noisy ones. Frankly it vaguely feels like the two latter options are there just to shepherd the ‘community’ (if there's such a thing) toward the least egregious variant and offer a semblance of discussion. It's not even necessarily bad that there's one obviously best option, if it's dictated by technical constraints—just, why bother me with the other two? If they're seriously considering the latter two options for us to be stuck with, that's very concerning, and I'll be nervous about the whole affair until something definite rolls out. Of course, it might be that the syntax authors foresaw some future problems that I don't, but their arguments aren't provided. In fact, I don't even see why the `@nest` marker is necessary at all. The W3C draft says, “Some valid nesting selectors, like `.foo &`, are disallowed”—but why? They introduced the `&` marker to tell nesting rules apart from anything else, but then it turns out that they can't do that with the marker either? See `&` anywhere in the selector, realize it's a nesting—how much lookahead is needed for this? `&` can't be in a property name or media rule, can it? Surely there's a reason for this constraint, only I can't figure it out—granted, I barely know anything about implementing a CSS parser. (Update: text cited by @pointlessone notes that a nest-selector might look like `color:hover & something`, which is indeed quite wacky and apparently befuddles the parser.) Also, philosophically, a more-verbose marker like `@nest` would help avoid the growth of ascii salad in the syntax (the way that Python and Lisp avoid it, compared to Bash and Perl)—specifically if the marker was used instead of both `@nest` and `&` together in those proposals. However, it's probably not such an issue in regard to a feature that's gonna get plenty of exercise and is practically core functionality.
- Ericson2314 4y ago
  - aasasd 4y ago
    The post makes it quite clear that all three proposals sprinkle some markers and constrain their use to avoid ambiguity for the parser, so not sure what you're talking about.
zarzavat 4y ago
To be honest, I just don't care anymore about plain CSS, it is just an intermediate representation to me. This feels like bikeshedding over the syntax for LLVM IR. Just add SCSS to the web inspector that's the only place where I'm still exposed to plain CSS.
- toastal 4y ago
  Wildly different experience in that I'm back to writing plain CSS on many simple to medium complexity projects because these tools aren't providing me enough value for the complexity and dependencies they bring. I've not written Sass or SCSS in about 4 years now, and when I do bring a tool, it's a countable number of PostCSS modules to bridge some gaps for features that haven't yet been upstreamed to all browsers.
skrebbel 4y ago
If i read this right, the only reason we can't just use & anywhere in the selector without some funky @nest indicator, is that browser vendors don't want their css parser to have unbounded lookahead just to figure out if something is a selector or a property. I gotta say, this strikes me as rather developer hostile. Now, developers have to appease a crippled parser by injecting @nest (or a billion brackets) strategically. The amount of devs that are going to have to scratch their heads at each of these three weird proposals is way more than the amount of devs building CSS parsers, so I think they don't have their priorities straight. I mean, in the 99.9% case, nested selectors are going to be at most some reasonable amount of tokens long. I understand wanting to avoid too many heap allocations but if that's the only issue, would it be that big a hack to first try to parse it with a bounded (but reasonably long) lookahead, and just reparse the whole thing in "insane CSS" mode with mallocs all over the place if the bounded one errors out? That way virtually all sites keep the fast small CSS parser and if some web dev really much challenge the engine with obscene code, it's supported but slow. They do this all over the JS engine, why can't CSS get a teeny tiny little bit of that attitude if it means CSS stays easy (enough) to learn?
- emn13 4y ago
  Stuff like that is, however, complex. Complexity breeds both slowness, expense to implement, and security risks (at the very least DoS risks). It may also require a pretty significant rearchitecture of existing css parsers, which will hinder adoption. It also makes future competing browser engines that little bit less likely. There's a bit of tradeoff here of devs vs. users. But regardless, I think the implicit syntax (as is) is clearly the worst anyhow - because it's important even for devs to avoid syntax with gotcha cases. Unfortunately the optional/implicit style can't always avoid @nest, and precisely in more complex cases it is required. That makes those even more confusing; I'm not a fan of adding complexity precisely where it hurts most, even if it's a little shorter in some cases. Had the implicit syntax _always_ allowed omitting @nest it'd be a different story, that's clearly best, but if browser-manufacturer's refuse that option, well, then let's not make it optional only in some cases. Personally, I'm not sold that this is a great feature at all, because nesting encourages high selector specificity, and tightly coupled details of the dom structure with css. That's still a recipe for specificity battles and refactoring gotchas, no matter the syntax. Nesting is a dangerous feature because it's pretty attractive superficially, but leads to pain way later in the development process: not good. In some niche cases (e.g. for pseudo-elements or media queries) there's never a maintainability problem with nesting, and hey, those are some of the cases where there's no parser ambiguity either, even with the implicit nesting syntax! I'd rather CSS restricted the nesting feature to those sane choices, than repeat SCSS's mistakes.
janpot 4y ago
There's "@nest" and "optional @nest". For a fair comparison, shouldn't there also be "optional brackets" next to "brackets"?
jacobp100 4y ago
I don’t think browsers should implement this. They’d need a much more robust parser with fewer edge cases than what SCSS implement - but this then means you can’t do stuff like BEM nesting. It’s also not necessary - you can do just fine not nesting. If you have so many selectors on one rule that the nesting is really benefitting you, it’s very likely you have bigger problems. They should just leave it to build tools.
skerit 4y ago
Yikes. I guess I would have to go with `&`, it isn't that awful. But we'll all still probably keep on using SCSS. So maybe something like `@nest` would be better to differentiate both, and the compiled result would still be a bit smaller.
tommica 4y ago
This should not be done on browser level, this should be done as a pre-processor, because any nested syntax is going to make older browsers faint, and to lessen the complexity of CSS, especially for beginners. That being said, if people really want this, then it definitely should not be something where the css file is going to be filled with "@nest" definitions. What about allowing SCSS-like syntax through something like `<link rel="stylesheet" href="styles.css" allow="nest,foo,bar" />` which then tells the parser to react in certain ways - for example if there is a rule "color:hover", then do the usual CSS parsing, while "color:hover {" means that there is a nested rule. That way the developer can opt-in to certain features, and you could even have it in the style tag with something like `<style allow="nest,foo,bar">...</style>` But then you have an issue of custom features allowed through the tag definition, where chrome can force their way with things even more.
- LocalPCGuy 4y ago
  Old browsers will just ignore it, just like if you give them nested SCSS without pre-processing it first. And for those that need to support older browsers, it'd probably still run through some sort of processor to output CSS for the older browsers. I see no reason to need to tell the parser what rules to parse for given how CSS works. As far as having numerous `@nest` definitions, I don't know if your concern is file size, but if so, that really isn't an issue - assuming use of gzip (or some similar compression), there is almost zero difference in file size for repeated use of `@nest`. I did a bunch of testing related to multiple @media blocks versus a single one (a long time ago) and found it didn't make any significant difference in file size - and that adds significantly more characters in the uncompressed version than @nest does.
Ericson2314 4y ago
What the hell. Asking people to vote with no context, hiding the only context that is provided (the "Why can't the exact nesting example shown above be the syntax for CSS nesting?"). This as an afront to both democracy (uninformed decisions only, please!) and technical decision making. I guess someone feels like the standards body is bikeshedding and wants to flip a "democracy coin". "Technical Trumpism" but honestly worse.
graderjs 4y ago
Nest definitely best. But instead of ampersand, let's use forward slash. It's very webby. Now for this very fascinating article on the history of the ampersand https://www.merriam-webster.com/words-at-play/the-history-of-ampersand https://www.merriam-webster.com/words-at-play/the-history-of...
- chrismorgan 4y ago
  Slash has a long history of being used as a tree descent combinator. That would make sense for the descendant combinator (“ ”) or the child combinator (“>”), and XPath does basically that (approximately “//” and “/” for descendant and child); but to use it instead of the ampersand here, that would be silly, because the ampersand is representing a selector, not a combinator. Ampersand has a long history, though much less popular, of being used to represent the source value of a text replacement (e.g. in Vim, :s/search/<&>/ will find “search” and replace it with “<search>”). This is pretty much exactly what’s going on here.
  - graderjs 4y ago
    I don't think it's silly. Is it really silly tho? I think it might be silly if you want to make everything historically align tho. Not everything has to. You might shoehorn yourself into an unideal outcome, trying to be backwards compat with the past. No? I like the conceptual similarity of stepping through parts (like a URL) with stepping through parts of the selector. Does it look good? form { margin: 1rem 0.5rem; background: transparent; / fieldset { border: none; padding: 0; background: white; } / label { color: darkslategray; / > input { border: thin solid; } / input { border: none; } / > button { font-size: larger; } } / a { text-decoration: none; } / :is(a, input, button, label) { color: inherit; } /:invalid { color: red; } } I think it looks really good actually. And I think the humble slash works really well as a stand in for a selector here. &&& are fucking noisy.
    - graderjs 4y ago
okonomiyaki3000 4y ago
Don't try to imagine yourself writing this code. You won't have to. We have preprocessors and they'll always be better than writing plain css. One of these standards will be what preprocessors of the future will need to write. The result will be that your compiled css will be smaller than what is possible with today's standard. So don't choose the option that's easiest for you to write, choose the one that's small.
- jrochkind1 4y ago
  I don't think what you describe is actually the goal of this proposal. I don't think anyone involved in the standards-making is looking at how many bytes of CSS would be saved -- I don't think the number is likely to be significant to anything, and I don't think this is the motivation. My understanding is that the intention is really to make CSS pre-processing less necessary, take features that people have found the need to have preprocessors for, and put them in the standard so the preprocessors aren't necessary for those features. I feel like I've seen some of the undesirability of preprocessors in my experience with sass/scss, which is having to make backwards incompatible changes in order to avoid conflicts with the evolution of CSS underneath it. Also just having to setup the pre-processor can actually be a significant infrastructure burden -- Rails had to kind of completely change how it supported SCSS when SASS moved to supporting dart-sass as essentially it's only supported implemnetation (no more libsass or ruby-sass). And then what happens when one of your dependencies uses scss and another uses postcss. I understand the desire to get back to not using pre-processors. You can definitely have your own goals and motivations and encourage people participating in this user poll to adopt them too. But if they aren't the goals the committee is working towards, they're unlikely to be achieved very well... and there are probably reasons they aren't.
  - okonomiyaki3000 4y ago
    I believe your understanding of the intention is correct and I totally agree with what you're saying about those involved in creating the standard. I just don't think they'll be able to evolve CSS into something preferable to using a preprocessor for many many years if ever.
- 4y ago
Leimi 4y ago
I feel like easy nesting shouldn't be included in CSS. The only few times it's actually useful and harmless to have nesting in Sass is when we want to do stuff like styling anchor's hover and focus styles at the same time. And this is already solved in CSS with :is() and :where(). Most of the time I see nesting used, it ends up either in a stylesheet that is less readable than without it, or in generating css classes that are way more specific than necessary.
AtNightWeCode 4y ago
I think both looks like something that I can live with. Perhaps @nest would be preferable. Why call it @nest though? @this or @scope or something maybe...
jhkiehna 4y ago
None of these seems meaningfully different enough for me to care. I could see myself getting used to any of them. Will be very happy when this goes through.
O__________O 4y ago
>> “official CSS version of this syntax is being strongly considered and we have a split in preference that we'd like to employ the help of the community to break the tie.” Where? Is there reason Google moderating this? Are there options Google has not suggested?
734129837261 4y ago
If that `color:hover` issue is the problem, then we should have pseudo classes like that change their syntax by using a double colon: color::hover { ... } Or maybe class names can't be protected CSS properties. So `<div class="color">` would need to become invalid. Protected names are commonplace in programming. And I'd argue it leads to better software development by causing less confusion. If they make it too verbose I'll just stick with SCSS. Honestly, I love vanilla CSS, but nesting is a huge need; it's the only reason I use SCSS to begin with.
chadlavi 4y ago
It's blindingly obvious that SCSS syntax for this should be used.
harrisi 4y ago
I'm reminded of OCaml's `let rec` which I'm somewhat surprised to not see any mention of, neither here nor the w3c's GitHub issues (https://github.com/w3c/csswg-drafts/issues https://github.com/w3c/csswg-drafts/issues). I was originally thinking of only treating nesting from a parent to child but the child to parent relationship does complicate things (especially since it seems much more likely with CSS to need to modify a parent - assigned from a library or framework, presumably - than typical imperative or functional programming). I originally thought a decorator-type syntax where "this definition includes nested elements" would be reasonable, since any user agent or linter or whatever could be in its rights (depending on spec) to look ahead a certain distance. Obviously this wouldn't actually be too reasonable with arbitrarily distant children. Anyway, I also initially thought I preferred the brackets since it's explicit and some of the best wording is odd to me, but I think after considering my own `let rec` idea I prefer the optional `@nest` syntax because the only odd case which is relevant - and often enough that succinct but obvious syntax is warranted - is the child->parent->* case. That's the only time I'd want a heads up while visibly parsing css.
progx 4y ago
Is it not obviously?
indirectlylit 4y ago
For me, the "equivalent css" is the most readable form in most of the examples given. I can understand how this would be useful in some situations. However, from a practical perspective, I've found that writing nested CSS ends up creating a tight coupling between DOM structure and style rules which makes everything more brittle and harder to refactor [1]. I've personally been spoiled by the scoped styles in Vue [2] which makes this style of isolation in CSS mostly unnecessary. It serves a similar purpose as related encapsulation ideas like shadow DOM, BEM, CSS modules, and styled components. [1] https://csswizardry.com/2012/05/keep-your-css-selectors-short/ https://csswizardry.com/2012/05/keep-your-css-selectors-shor... [2] https://vue-loader.vuejs.org/guide/scoped-css.html https://vue-loader.vuejs.org/guide/scoped-css.html
- Mlller 4y ago
  Yes, I cannot agree more. I did the survey in the vain hope that I could leave a comment or even vote for “no nesting”, i.e. “equivalent CSS”. Most of the given examples are great evidence – some concerningly great evidence – for Tim Petersʼ “flat is better than nested”: (1 and 2:) .foo { color: red; @nest .parent & { color: blue; } } (3:) .foo { color: red; { .parent & { color: blue; } } } (Without nesting:) .foo { color: red; } .parent .foo { color: blue; } The nested variants, for my sense, foreshadow grave technical debt – in specs, docs, browser code and CSS files.
d--b 4y ago
Well these all suck. Obviously `@nest always` and `brackets` are the same in disguise, and are here cause they're conceptually cleaner. The problem with both of these is that they're unnecessarily verbose. Why not have a shorter token than `@nest` and something that doesn't want more indenting (like `{}`)? For example `\`? And then if you want to make things a little less verbose, just assume the first character is going to be `&` cause that's going to be 99% of use cases. And then you get something like this: foo { color: blah; \ h2 { font-weight: bold } \ h3 { font-weight: bolder } \ i > & { ... } } But no one ever listens to me!
- LocalPCGuy 4y ago
  Isn't that effectively what you get with the first option (with the `&` character)? You don't need `@nest` unless you want to embed the ampersand as anything other than the first character (which, I'll admit, is one of my major use cases). But given the prevalence of @ elements in CSS already (like @media for example), I'm ok learning/teaching @nest for those specific cases.
ImPleadThe5th 4y ago
Yeah I don't see whats wrong with the current css solution? Drilling down tags (the current implementation) just makes it more explicit in my opinion. I feel like nesting is going to take nice flat easy-to-read css and make it too complex and deep.
tolmasky 4y ago
If verbosity is the issue we're trying to solve for then it seems obvious that the answer is to simply use the nest emoji instead of "@nest". https://emojipedia.org/nest-with-eggs/ https://emojipedia.org/nest-with-eggs/
no_wizard 4y ago
I have a 4th idea for syntax. Use a similar syntax to media querys, where you use the `@nested` query with parentheses. Maybe too verbose? .has-nesting { @nested (> .nested) { /* rules */ } }
windows2020 4y ago
a { ... } a { ... } a b { ... } a > b { ... } is to is to a { a > { b { ... } b { ... } } } That's what I want. And it appears to fail correctly. The lookahead argument doesn't warrant poor syntax.
geophertz 4y ago
How about no? Why do we need to add further complexity into the already complex thing that are browsers? As the post mentions at the beginning, this can already be done with pre-processing. What do we gain by having more syntax sugar?
- LocalPCGuy 4y ago
  The ability to eliminate the need for pre-processors.
masswerk 4y ago
I'm in favor with option 1 (@nest, &). Reasoning: I do not see much sense in the use of additional brackets (option 3), since "&" already serves as a separator. I also do not see much sense in the use of the more verbose "@nest" (option 2), since conventional selector syntax uses single-character keywords already and there is no real parallel to things like "@media" or "@page" (as this isn't related to rendering and formats).
micromacrofoot 4y ago
Oh my, I much prefer @nest only even though it's verbose. The bracket method has good intentions, but a readability nightmare for me.
dsmmcken 4y ago
What I care about would be a SCSS to CSS nesting migration tool. Has anybody started work on that? 95% of my scss usage is simply nesting, variables, and color mix functions. Which means I could pretty much switch to a native solution when available. I don't really care which is chosen, I can learn to live with whatever.
amichal 4y ago
The cat is out of the bag but, one fear i have is how easy it is to abuse nested selectors this way. When I first was exposed to SCSS I also started seeing selectors like `.helpPage .faqSection .sidebar ul li` in lots of codebases I touched because it seems so neat and tidy in SCSS and made it easy to make that CMS generated list look just the way you want it to without injecting local class= attributes. Then 6 months later you want to restructure your containers and all your magic selectors work differently. Deep nesting is a trap those of us who have tried to maintain SCSS eventually learn and we use all sorts of naming conventions (e.g. BEM) to avoid it but for beginners having it there without tooling will probably mean we see even more of it in the wild at first. Edit: I still voted for `@nest` -- CCS is a pretty complex language for sure but I think it's terse expressiveness is why it's been successful.
- LocalPCGuy 4y ago
  I agree in regards to people abusing selectors, but I see that kind of code even without nesting. People don't understand (and IMO don't bother to learn) CSS specificity. Then they wonder why their CSS falls over.
butz 4y ago
Has Google finally learned something from the alert change debacle and is asking for developer feedback first?
rglover 4y ago
Thinking about this as someone who teaches web dev: this shouldn't happen. As others have mentioned, this goes just far-enough past the scope of CSS to just leave as a pre-processor feature. This will be an absolute nightmare for beginners and lead to a lot of messes/time wasted chasing bugs. If you can't get the as-is SCSS syntax natively without a bunch of hacks, it shouldn't be done (a bummer, as I'd love to have that natively). What could (should?) happen is codifying a pre-processor model into the standards track. Have a standard and then make some library the reference implementation.
aslilac 4y ago
I wish there was fourth option for “brackets but optional”. I like the brackets syntax, it’d be nice to omit them if you only have rules starting with &, similar to the “directive but optional” syntax.
wnevets 4y ago
I prefer the way & .class looks, its just like LESS
encryptluks2 4y ago
One thing CSS still can't do is to properly put multiple elements in a single flex or grid without having to wrap it with a div. I'm glad to see work being done on CSS but I somehow seem to frequently run into things CSS still can't do and there is always some proposal that isn't supported in both Chrome and Firefox.
andrewrothman 4y ago
It seems like the ideal approach would be "proving" syntax proposals by implementing them in a preprocessor first and then later trying to standardize the syntax if it gains traction. It sounds like there are technical reasons for why that didn't work for the case of SCSS-like nesting, which is disappointing but understandable... if that's the case I think the right approach is to take these new proposals and "go back to square one" (preprocessor) vs. "go straight to standardizing something new".
IYasha 4y ago
I see, chrome developers are, as usual, very busy people. No time to waste - CSS won't break itself! (@nest {sarcasm: red;} )
claar 4y ago
I vote for #4 - use SCSS syntax with bounded forward-lookahead. > CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS. Then choose a bound! Make it big enough that it'll cover 99.9% of use cases, ignore any CSS rules beyond the bound with a console warning, and go on with life... This seems so obvious that I feel I must be overlooking something. Perhaps the bound would be so big, that when parsing multiple stylesheets in parallel the memory use would be unacceptable?
zelphirkalt 4y ago
*backets -> curly braces
coxmichael 4y ago
Can we not just have something like: a { &:hover {…} &:parent(.theme):hover {…} } No crazy selectors with an ampersand in the middle allowed, but a way to apply a parent or ancestor selector, a bit like :where() or :is(). There could be :in() for ancestors. No one needs this monstrosity: dialog { @nest html:has(&[open]) {…} }
- toastal 4y ago
  I'd be happy if they just left it here. You can only nest pseudo-classes and pseudo-selectors, and everything else either use your own tool to generate the CSS or just not not nest.
shaunxcode 4y ago
Use sexpressions?
arxpoetica 4y ago
I hate it. I hate it all. I voted for `@nest all` because I don't think it's a feature I will EVER use, so I wanted it to be dumb obvious that someone is using it by explicitly putting @nest in the code. That way if I encounter it in the wild, I'll be less likely to confuse it with SCSS nesting, for example.
MrPatan 4y ago
I guess I'm old and set in my ways, but I just don't want any of this. I never missed nesting. Don't Shadow DOM and components kind of make this not very important? I've mainly seen nesting used in huge multi-kloc scss files that applied to the whole site, which I find a bad idea anyway. I guess what I mean is: for small pieces of CSS it doesn't matter, and for huge nested structures.... you shouldn't do it
miragecraft 4y ago
I support @nest always with implicit &, so @nest .child {} equals @nest & .child {}

217 points by feross 4y ago

I was hoping the new CSS syntax for nesting would work just like in Sass, simple and intuitive. Unfortunately, it's apparently too ambiguous and inefficient for parsing. > Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration.. > It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. > CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS. https://drafts.csswg.org/css-nesting/#nesting https://drafts.csswg.org/css-nesting/#nesting

somishere 4y ago

Implicit @nest every time for me .. except for example 8 where brackets (finally) made some sense. Also intrigued by the example 9 `&[open]` edge case. Wild. Honestly tho, I think scss has it right where ampersand is only used for grouping / parenting.

Etheryte 4y ago

Perhaps I simply don't see the ambiguity after having used Scss, Less and the like for a long time, but isn't the simple `&` by far the best option here? The other two are absurdly verbose without offering any real benefit.

esteth 4y ago
The simple '&' requires infinite lookahead to parse.
- aasasd 4y ago
  Afaict the lookahead problem refers not to the proposals, but to a syntax without these extra markers altogether. Which is why all the proposals have some markers.
- jimmaswell 4y ago
  So what? That's a complete non-problem.
- jeshin 4y ago
  no it doesn't, the simple no-prefix solution requires infinite lookahead

donatj 4y ago

All of these are stupid. Why can’t we just have the scss syntax? It’s already proven.

mrcartmeneses 4y ago
100% agree. The community has already chosen the syntax it wants by voting with its feet for SCSS
- esteth 4y ago
  Except that syntax requires infinite lookahead to parse. It's feasible when you're running a preprocessor on your own code one time, but not feasible for the browser to do on unknown code on every stylesheet it encounters.
  - bornfreddy 4y ago
    I'm quite sure some edge cases could be forbidden to speed ip parsing. The most common use in my experience is simple nesting ("& .child"), and I would argue other forms should be avoided for readability reasons anyway. But finding 3 other solutions (because of "performance"), not promoting them through transpiling, and then forcing them on web devs seems... googley. Not the first improvement they forced down our throats and unfortunately not the last. /rant
  - marcosdumay 4y ago
    You can just bound the lookahead on the browser by some large number, and accept smaller performance loses for parsing. Anyway, if your possibilities are only nested selector and property, why don't you compute both until they are not ambiguous anymore? You don't need backtracking.
- myfonj 4y ago
  Jake Archibald points out [1] section [2] in that page that explains it somehow. Haven't grokked it yet, but I see that popular SASS (SCSS)-BEM way of doing .block { &__element { &--modifier { p: v; } } } for getting .block__element--modifier { p: v; } could really be problematic from CSS parser perspective. Also in SASS `&` really is kinda placeholder and I think you can do stuff like .x { &+&+& { p:v; } } to get .x + .x + .x { p: v; } what again seems problematic. (But again, I don't say I've grasped that fully.) [1] https://twitter.com/jaffathecake/status/1552200992179077126 https://twitter.com/jaffathecake/status/1552200992179077126 [2] https://developer.chrome.com/blog/help-css-nesting/#:~:text=Why%20can%27t%20the%20exact%20nesting%20example%20shown%20above%20be%20the%20syntax%20for%20CSS%20nesting%3F https://developer.chrome.com/blog/help-css-nesting/#:~:text=...

di4na 4y ago

None of them honestly. All of them are atrocious to type and parse for a human. The option 1 is probably the best but urgh

emn13 4y ago
I think option 1 is the worst, because it's not actually optional; it's required precisely when css selectors become complex. That the kind of gotcha that just makes everything harder to explain and read. I hope the proposal fails entirely, and that no nesting syntax is adopted. It's not worth it, and nesting in SCSS is abused more often than not anyhow. There are a few exceptions like pseudo-elements and media queries that are always harmless, but most nesting is just asking for specificity gotchas later, or component refactoring surprises.

richthegeek 4y ago

Looks like another round of W3C bike-shedding an existing easy-to-use and well-understood community standard until it's godawful to work with and half as useful. Gotta love standards bodies!

mrcartmeneses 4y ago
- madeofpalk 4y ago
  This is just css. No one's going to die.
- blowski 4y ago
  No, these are the kind of people who are deliberating on the best syntax to support millions of projects using CSS for the next 30 years. They have to factor in backwards compatibility, extensibility, performance, security, accessibility, responsiveness, and lots of other NFRs. Once it’s out there, it has to be supported for a long time. It’s worth deliberating to get right. Nobody will die because they took their time.
  - Aeolun 4y ago
    Kinda? People have been working with their preferred syntax for oh, the last 10 years or so? It’s scss. No point in making a poll with an answer that’s already decided.
    - blowski 4y ago
      They mention in the post this has issues because browsers don’t have a build step in the same way Sass has. What’s your solution for that?
      - JoBrad 4y ago
        Support look ahead to some limit, then fail that css resource, with an error message that is more verbose in the dev console.

mrcartmeneses 4y ago

Just make it like scss. It’s what most people that use nesting in css already know and has been shown to work

singaporecode 4y ago

krajzeg 4y ago

These all feel like an overengineered solution in search of a problem, with some degree of tunnel vision in that all three proposals try to support the same broad set of capabilities. It looks like somebody decided that nesting support must somehow support "reverse nesting", eg. that you'd like to define what happens to .foo when it's inside a .bar, but nested inside the definition for .foo: .foo { .bar > .foo { ... } } Does anybody actually want this? It feels counter-intuitive and weird, and with the syntaxes proposed, seems to provides little benefit compared to just doing it as the old ".bar > .foo" without nesting. If you drop the requirement for nesting to work in reverse, you can just go with the proven SCSS syntax which is extremely clear, straightforward to use, and requires 0 extra characters typed. EDIT: Apparently the '&' or some other special token is required to prevent the need for unlimited lookahead while parsing. This is actually explained behind a folded caption in the article, which I initially missed.

akdor1154 4y ago
The @media application of this seems useful, but yeah arbitrary parents seems not a must-have.
- krajzeg 4y ago
  Apparently, those already work differently than other selectors in the proposals (example 7): .foo { display: grid; @media (width => 30em) { grid-auto-flow: column; } } I would expect "@nest @media (width => 30em) & {" for consistency with how it works everywhere else, but apparently @media is already special anyway in the "@nest" proposal. I agree that this syntax could be convenient, though I'm actually a fan of having all the "@media" changes in one place, which is what the current syntax forces.
somishere 4y ago
Apologies if I misunderstand, but your "reverse nesting" syntax already works with scss. I.e. `.a{ .b & {}}` => `.b .a {}` ... I'd quite honestly use it fairly often, usually with state/data modifiers on an ancestor (or ancestor sibling!)

pointlessone 4y ago

I see that many didn't read the hidden part of the post that explains why SCSS version can not be used. Here's the relevant excerpt. > ## Why can’t everything be directly nested? > Nesting style rules naively inside of other style rules is, unfortunately, ambiguous—the syntax of a selector overlaps with the syntax of a declaration, so an implementation requires unbounded lookahead to tell whether a given bit of text is a declaration or the start of a style rule. > For example, if a parser starts by seeing color:hover ..., it can’t tell whether that’s the color property (being set to an invalid value...) or a selector for a <color> element. It can’t even rely on looking for valid properties to tell the difference; this would cause parsing to depend on which properties the implementation supported, and could change over time. > Requiring directly-nested style rules to use nest-prefixed selectors works around this problem—an & can never be part of a declaration, so the parser can immediately tell it’s going to be parsing a selector, and thus a nested style rule. > Some non-browser implementations of nested rules do not impose this requirement. It is, in most cases, eventually possible to tell properties and selectors apart, but doing so requires unbounded lookahead in the parser; that is, the parser might have to hold onto an unknown amount of content before it can tell which way it’s supposed to be interpreting it. CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS.

krajzeg 4y ago
Thanks for pointing this out, I indeed missed that (it's hidden behind a folded caption). It still doesn't explain why all the proposals feel the need to be more powerful than SCSS nesting (allowing "reverse nested" definitions where the element being nested in is not at the start), but it does explain the need for "&". EDIT: Actually, it looks like SCSS supports the same thing by using '&' anywhere in the definition. I'll just stop posting since it looks like my knowledge is too rusty to contribute positively.
- Semaphor 4y ago
  I’m not sure if I understand you correctly, but I think SCSS does actually support that. dialog { html:has(&[open]) { overflow: hidden; } } Is possible annd creates html:has(dialog[open]) {overflow: hidden;}

lovasoa 4y ago

So now we discuss web standards on chrome.com ? This looks like the beginning of the end of a free web governed standards established by an independent body. I would have expected such an article to be published on w3.org...

mattgperry 4y ago
Why didn't they publish one then?
oefrha 4y ago
Any person can publish a blog post discussing web standards on the “free web”. You’re welcome to publish one yourself.
- echelon 4y ago
  Too many Google engineers working on this to keep up.
tannhaeuser 4y ago
It also looks like asking the general public for a go to make CSS even more complicated, when we all know it's a one-way ticket to Chrome dominance, ie a rhetoric dictators have been using. Note the absence of the option to "do nothing" and keep good-damn CSS as it is already after 25+ years of tinkering that haven't solved its problems. I mean even one of the long-term editors of the CSS spec has raised hands and warned against including ever more inessential and author-oriented features [1]. That was almost 14 years ago. [1]: https://www.w3.org/People/Bos/CSS-variables https://www.w3.org/People/Bos/CSS-variables
- aasasd 4y ago
  > That was almost 14 years ago. Now that's a page that can be dated by its look.
  - noSyncCloud 4y ago

Zoadian 4y ago

can we just get native styl support into the browser please

saagarjha 4y ago

IMO this is one of the things, like TypeScript, where transpiling before hitting the browser is good enough considering the downsides of baking this into three web engines.

toastal 4y ago

Folks undervalue how much `:is()` and `:where()` can eliminate nesting and works in most browsers right now.

wwalexander 4y ago

> determining which should be championed through to a specification candidate Didn’t they mean “implemented in Chrome and therefore forced into the CSS standard due to browser monoculture”?

jaffathecake 4y ago
No. This research is ahead of a CSS working group meeting, where its inclusion into the standard will be discussed.

cphoover 4y ago

I really don't find nesting to be a necessary part of the CSS spec and in fact find deeply nested CSS rules harder to reason about.

LAC-Tech 4y ago

I'm glad this is happening. Languages that transpile to CSS require extra tooling and setup, and if there's one thing our web apps have too much of it's tooling and setup. I will be able to make much stronger cases to get rid of SASS, SCSS etc when this happens.

kazinator 4y ago

How about: x = .nesting { color: hotpink; } y = x > .is { color: rebeccapurple; } y > .awesome { color: deeppink; } plus: x = .nesting; y = x > .is; z = y > .awesome; x { color: hotpink; } y { color: rebeccapurple; } z { color: deeppink; } The names x, y and z aren't ambiguous because they are lexically defined. They could be allowed to shadow tags: pre = .foo > .bar; then from that point on, pre isn't the HTML tag, but the above definition. Or else tags could be reserved: cannot use those as names. (Causing trouble when new tags get introduced; bad idea.) Regarding the @nest syntax, why couldn't it look like an attribute? ...sel... { color: blue; nest: > .whatever { ... } } Or just the colon: ...sel... { color: blue; : > .whatever { ... } } Why use containment to express the nesting? What is being nested is the selectors. The braces group something else: the attributes affected by selectors. Why would nested selectors have to go into those braces? The + character at the start of a rule could mean "the selector of the previous rule": .nesting { color: hotpink } + > .is { color: rebeccapurple } + > .awesome { color: deeppink } Or use a master outer brace for this: { .nesting { color: hotpink } > .is { color: rebeccapurple } > .awesome { color: deeppink } } The understanding is that the rules grouped in the brace have a cumulative selector, rather than independent selectors. Or what if braces just group, and @nest (or whatever) is required to indicate the selector stacking semantics: @stack { .nesting { color: hotpink; } > .is { color: rebeccapurple; } > .awesome { color: deeppink; } } Now you can have N levels of selector refinement without N levels of syntactic containment. The containment is still available: @stack { .nesting { color: hotpink; } > .is { color: rebeccapurple; } { /* parallel rules: not a stack */ .awesome { color: deeppink; } .terrific { color: yellow; } } @stack { /* stack-in-stack, cross-producting. */ .even { color: red; } .more { color: green; } .nested { color: blue; } } } Here, because the nested @stack follows a block of parallel rules, a Cartesian product semantics can come into effect. That is to say, it is equivalent to: @stack { .nesting { color: hotpink; } > .is { color: rebeccapurple; } { @stack { .awesome { color: deeppink; } .even { color: red; } .more { color: green; } .nested { color: blue; } } @stack { .terrific { color: yellow; } .even { color: red; } .more { color: green; } .nested { color: blue; } } } } The @stack following a parallel rule causes the @stack to distribute into the parallel branches. Kind of like Bash brace expansion: $ echo nesting-is-{awesome,terrific}-even-more-nested nesting-is-awesome-even-more-nested nesting-is-terrific-even-more-nested

azangru 4y ago

I like the first option, with the ampersand. Having to write @nest looks yucky, and an extra pair of curlies is confusing.

Aeolun 4y ago

Honestly, if SCSS works, then I don’t see how they can say it’ll be a problem in the browser. It already works, lets not require everyone to redo everything they already have. Have the browser show a warning in the style of “An unbounded lookahead is making this page slow” when, and if it happens, and the site owner can do something about that crazy thing.

its_bbq 4y ago
Yes but the cost is paid once by the developer at compile time. I'm this case, the cost would be paid by every visitor on every page visit
- Aeolun 4y ago
  That’s already true for all the Javascript tracking and ads. It seems silly to now worry about a few extra ms that it takes the CSS parser to resolve it’s difficulties. Maybe if they specified how long this ‘infinite’ lookahead takes in all their scenarios, it would be more compelling.
  - its_bbq 4y ago
    Tracking and ads scripts aren't special here. Yes page rendering is paid by the browser every time, and this group of people is specifically worried about the CSS part of that process. They're separate concerns and don't need to influence each other design wise
    - seba_dos1 4y ago
      Also, CSS is often used in other contexts than web browsing as well.
      - its_bbq 4y ago
        Really? I'm not aware of any except exports of the browser stack like Electron.

meerita 4y ago

I learned a long time ago that this kind of approach only brings problems in the long run: you end up building house of cards all the time. All our problems went away when we adopted functional CSS.

aasasd 4y ago

Choosing only among the given proposals, what I see is one clear, concise and reasonably elegant syntax, and two ugly and noisy ones. Frankly it vaguely feels like the two latter options are there just to shepherd the ‘community’ (if there's such a thing) toward the least egregious variant and offer a semblance of discussion. It's not even necessarily bad that there's one obviously best option, if it's dictated by technical constraints—just, why bother me with the other two? If they're seriously considering the latter two options for us to be stuck with, that's very concerning, and I'll be nervous about the whole affair until something definite rolls out. Of course, it might be that the syntax authors foresaw some future problems that I don't, but their arguments aren't provided. In fact, I don't even see why the `@nest` marker is necessary at all. The W3C draft says, “Some valid nesting selectors, like `.foo &`, are disallowed”—but why? They introduced the `&` marker to tell nesting rules apart from anything else, but then it turns out that they can't do that with the marker either? See `&` anywhere in the selector, realize it's a nesting—how much lookahead is needed for this? `&` can't be in a property name or media rule, can it? Surely there's a reason for this constraint, only I can't figure it out—granted, I barely know anything about implementing a CSS parser. (Update: text cited by @pointlessone notes that a nest-selector might look like `color:hover & something`, which is indeed quite wacky and apparently befuddles the parser.) Also, philosophically, a more-verbose marker like `@nest` would help avoid the growth of ascii salad in the syntax (the way that Python and Lisp avoid it, compared to Bash and Perl)—specifically if the marker was used instead of both `@nest` and `&` together in those proposals. However, it's probably not such an issue in regard to a feature that's gonna get plenty of exercise and is practically core functionality.

Ericson2314 4y ago
- aasasd 4y ago
  The post makes it quite clear that all three proposals sprinkle some markers and constrain their use to avoid ambiguity for the parser, so not sure what you're talking about.

zarzavat 4y ago

To be honest, I just don't care anymore about plain CSS, it is just an intermediate representation to me. This feels like bikeshedding over the syntax for LLVM IR. Just add SCSS to the web inspector that's the only place where I'm still exposed to plain CSS.

toastal 4y ago
Wildly different experience in that I'm back to writing plain CSS on many simple to medium complexity projects because these tools aren't providing me enough value for the complexity and dependencies they bring. I've not written Sass or SCSS in about 4 years now, and when I do bring a tool, it's a countable number of PostCSS modules to bridge some gaps for features that haven't yet been upstreamed to all browsers.

skrebbel 4y ago

If i read this right, the only reason we can't just use & anywhere in the selector without some funky @nest indicator, is that browser vendors don't want their css parser to have unbounded lookahead just to figure out if something is a selector or a property. I gotta say, this strikes me as rather developer hostile. Now, developers have to appease a crippled parser by injecting @nest (or a billion brackets) strategically. The amount of devs that are going to have to scratch their heads at each of these three weird proposals is way more than the amount of devs building CSS parsers, so I think they don't have their priorities straight. I mean, in the 99.9% case, nested selectors are going to be at most some reasonable amount of tokens long. I understand wanting to avoid too many heap allocations but if that's the only issue, would it be that big a hack to first try to parse it with a bounded (but reasonably long) lookahead, and just reparse the whole thing in "insane CSS" mode with mallocs all over the place if the bounded one errors out? That way virtually all sites keep the fast small CSS parser and if some web dev really much challenge the engine with obscene code, it's supported but slow. They do this all over the JS engine, why can't CSS get a teeny tiny little bit of that attitude if it means CSS stays easy (enough) to learn?

emn13 4y ago
Stuff like that is, however, complex. Complexity breeds both slowness, expense to implement, and security risks (at the very least DoS risks). It may also require a pretty significant rearchitecture of existing css parsers, which will hinder adoption. It also makes future competing browser engines that little bit less likely. There's a bit of tradeoff here of devs vs. users. But regardless, I think the implicit syntax (as is) is clearly the worst anyhow - because it's important even for devs to avoid syntax with gotcha cases. Unfortunately the optional/implicit style can't always avoid @nest, and precisely in more complex cases it is required. That makes those even more confusing; I'm not a fan of adding complexity precisely where it hurts most, even if it's a little shorter in some cases. Had the implicit syntax _always_ allowed omitting @nest it'd be a different story, that's clearly best, but if browser-manufacturer's refuse that option, well, then let's not make it optional only in some cases. Personally, I'm not sold that this is a great feature at all, because nesting encourages high selector specificity, and tightly coupled details of the dom structure with css. That's still a recipe for specificity battles and refactoring gotchas, no matter the syntax. Nesting is a dangerous feature because it's pretty attractive superficially, but leads to pain way later in the development process: not good. In some niche cases (e.g. for pseudo-elements or media queries) there's never a maintainability problem with nesting, and hey, those are some of the cases where there's no parser ambiguity either, even with the implicit nesting syntax! I'd rather CSS restricted the nesting feature to those sane choices, than repeat SCSS's mistakes.

janpot 4y ago

There's "@nest" and "optional @nest". For a fair comparison, shouldn't there also be "optional brackets" next to "brackets"?

jacobp100 4y ago

I don’t think browsers should implement this. They’d need a much more robust parser with fewer edge cases than what SCSS implement - but this then means you can’t do stuff like BEM nesting. It’s also not necessary - you can do just fine not nesting. If you have so many selectors on one rule that the nesting is really benefitting you, it’s very likely you have bigger problems. They should just leave it to build tools.

skerit 4y ago

Yikes. I guess I would have to go with `&`, it isn't that awful. But we'll all still probably keep on using SCSS. So maybe something like `@nest` would be better to differentiate both, and the compiled result would still be a bit smaller.

tommica 4y ago

This should not be done on browser level, this should be done as a pre-processor, because any nested syntax is going to make older browsers faint, and to lessen the complexity of CSS, especially for beginners. That being said, if people really want this, then it definitely should not be something where the css file is going to be filled with "@nest" definitions. What about allowing SCSS-like syntax through something like `<link rel="stylesheet" href="styles.css" allow="nest,foo,bar" />` which then tells the parser to react in certain ways - for example if there is a rule "color:hover", then do the usual CSS parsing, while "color:hover {" means that there is a nested rule. That way the developer can opt-in to certain features, and you could even have it in the style tag with something like `<style allow="nest,foo,bar">...</style>` But then you have an issue of custom features allowed through the tag definition, where chrome can force their way with things even more.

LocalPCGuy 4y ago
Old browsers will just ignore it, just like if you give them nested SCSS without pre-processing it first. And for those that need to support older browsers, it'd probably still run through some sort of processor to output CSS for the older browsers. I see no reason to need to tell the parser what rules to parse for given how CSS works. As far as having numerous `@nest` definitions, I don't know if your concern is file size, but if so, that really isn't an issue - assuming use of gzip (or some similar compression), there is almost zero difference in file size for repeated use of `@nest`. I did a bunch of testing related to multiple @media blocks versus a single one (a long time ago) and found it didn't make any significant difference in file size - and that adds significantly more characters in the uncompressed version than @nest does.

Ericson2314 4y ago

What the hell. Asking people to vote with no context, hiding the only context that is provided (the "Why can't the exact nesting example shown above be the syntax for CSS nesting?"). This as an afront to both democracy (uninformed decisions only, please!) and technical decision making. I guess someone feels like the standards body is bikeshedding and wants to flip a "democracy coin". "Technical Trumpism" but honestly worse.

graderjs 4y ago

Nest definitely best. But instead of ampersand, let's use forward slash. It's very webby. Now for this very fascinating article on the history of the ampersand https://www.merriam-webster.com/words-at-play/the-history-of-ampersand https://www.merriam-webster.com/words-at-play/the-history-of...

chrismorgan 4y ago
Slash has a long history of being used as a tree descent combinator. That would make sense for the descendant combinator (“ ”) or the child combinator (“>”), and XPath does basically that (approximately “//” and “/” for descendant and child); but to use it instead of the ampersand here, that would be silly, because the ampersand is representing a selector, not a combinator. Ampersand has a long history, though much less popular, of being used to represent the source value of a text replacement (e.g. in Vim, :s/search/<&>/ will find “search” and replace it with “<search>”). This is pretty much exactly what’s going on here.
- graderjs 4y ago
  I don't think it's silly. Is it really silly tho? I think it might be silly if you want to make everything historically align tho. Not everything has to. You might shoehorn yourself into an unideal outcome, trying to be backwards compat with the past. No? I like the conceptual similarity of stepping through parts (like a URL) with stepping through parts of the selector. Does it look good? form { margin: 1rem 0.5rem; background: transparent; / fieldset { border: none; padding: 0; background: white; } / label { color: darkslategray; / > input { border: thin solid; } / input { border: none; } / > button { font-size: larger; } } / a { text-decoration: none; } / :is(a, input, button, label) { color: inherit; } /:invalid { color: red; } } I think it looks really good actually. And I think the humble slash works really well as a stand in for a selector here. &&& are fucking noisy.
  - graderjs 4y ago

okonomiyaki3000 4y ago

Don't try to imagine yourself writing this code. You won't have to. We have preprocessors and they'll always be better than writing plain css. One of these standards will be what preprocessors of the future will need to write. The result will be that your compiled css will be smaller than what is possible with today's standard. So don't choose the option that's easiest for you to write, choose the one that's small.

jrochkind1 4y ago
I don't think what you describe is actually the goal of this proposal. I don't think anyone involved in the standards-making is looking at how many bytes of CSS would be saved -- I don't think the number is likely to be significant to anything, and I don't think this is the motivation. My understanding is that the intention is really to make CSS pre-processing less necessary, take features that people have found the need to have preprocessors for, and put them in the standard so the preprocessors aren't necessary for those features. I feel like I've seen some of the undesirability of preprocessors in my experience with sass/scss, which is having to make backwards incompatible changes in order to avoid conflicts with the evolution of CSS underneath it. Also just having to setup the pre-processor can actually be a significant infrastructure burden -- Rails had to kind of completely change how it supported SCSS when SASS moved to supporting dart-sass as essentially it's only supported implemnetation (no more libsass or ruby-sass). And then what happens when one of your dependencies uses scss and another uses postcss. I understand the desire to get back to not using pre-processors. You can definitely have your own goals and motivations and encourage people participating in this user poll to adopt them too. But if they aren't the goals the committee is working towards, they're unlikely to be achieved very well... and there are probably reasons they aren't.
- okonomiyaki3000 4y ago
  I believe your understanding of the intention is correct and I totally agree with what you're saying about those involved in creating the standard. I just don't think they'll be able to evolve CSS into something preferable to using a preprocessor for many many years if ever.
4y ago

Leimi 4y ago

I feel like easy nesting shouldn't be included in CSS. The only few times it's actually useful and harmless to have nesting in Sass is when we want to do stuff like styling anchor's hover and focus styles at the same time. And this is already solved in CSS with :is() and :where(). Most of the time I see nesting used, it ends up either in a stylesheet that is less readable than without it, or in generating css classes that are way more specific than necessary.

AtNightWeCode 4y ago

I think both looks like something that I can live with. Perhaps @nest would be preferable. Why call it @nest though? @this or @scope or something maybe...

jhkiehna 4y ago

None of these seems meaningfully different enough for me to care. I could see myself getting used to any of them. Will be very happy when this goes through.

O__________O 4y ago

>> “official CSS version of this syntax is being strongly considered and we have a split in preference that we'd like to employ the help of the community to break the tie.” Where? Is there reason Google moderating this? Are there options Google has not suggested?

734129837261 4y ago

If that `color:hover` issue is the problem, then we should have pseudo classes like that change their syntax by using a double colon: color::hover { ... } Or maybe class names can't be protected CSS properties. So `<div class="color">` would need to become invalid. Protected names are commonplace in programming. And I'd argue it leads to better software development by causing less confusion. If they make it too verbose I'll just stick with SCSS. Honestly, I love vanilla CSS, but nesting is a huge need; it's the only reason I use SCSS to begin with.

chadlavi 4y ago

It's blindingly obvious that SCSS syntax for this should be used.

harrisi 4y ago

I'm reminded of OCaml's `let rec` which I'm somewhat surprised to not see any mention of, neither here nor the w3c's GitHub issues (https://github.com/w3c/csswg-drafts/issues https://github.com/w3c/csswg-drafts/issues). I was originally thinking of only treating nesting from a parent to child but the child to parent relationship does complicate things (especially since it seems much more likely with CSS to need to modify a parent - assigned from a library or framework, presumably - than typical imperative or functional programming). I originally thought a decorator-type syntax where "this definition includes nested elements" would be reasonable, since any user agent or linter or whatever could be in its rights (depending on spec) to look ahead a certain distance. Obviously this wouldn't actually be too reasonable with arbitrarily distant children. Anyway, I also initially thought I preferred the brackets since it's explicit and some of the best wording is odd to me, but I think after considering my own `let rec` idea I prefer the optional `@nest` syntax because the only odd case which is relevant - and often enough that succinct but obvious syntax is warranted - is the child->parent->* case. That's the only time I'd want a heads up while visibly parsing css.

progx 4y ago

Is it not obviously?

indirectlylit 4y ago

For me, the "equivalent css" is the most readable form in most of the examples given. I can understand how this would be useful in some situations. However, from a practical perspective, I've found that writing nested CSS ends up creating a tight coupling between DOM structure and style rules which makes everything more brittle and harder to refactor [1]. I've personally been spoiled by the scoped styles in Vue [2] which makes this style of isolation in CSS mostly unnecessary. It serves a similar purpose as related encapsulation ideas like shadow DOM, BEM, CSS modules, and styled components. [1] https://csswizardry.com/2012/05/keep-your-css-selectors-short/ https://csswizardry.com/2012/05/keep-your-css-selectors-shor... [2] https://vue-loader.vuejs.org/guide/scoped-css.html https://vue-loader.vuejs.org/guide/scoped-css.html

Mlller 4y ago
Yes, I cannot agree more. I did the survey in the vain hope that I could leave a comment or even vote for “no nesting”, i.e. “equivalent CSS”. Most of the given examples are great evidence – some concerningly great evidence – for Tim Petersʼ “flat is better than nested”: (1 and 2:) .foo { color: red; @nest .parent & { color: blue; } } (3:) .foo { color: red; { .parent & { color: blue; } } } (Without nesting:) .foo { color: red; } .parent .foo { color: blue; } The nested variants, for my sense, foreshadow grave technical debt – in specs, docs, browser code and CSS files.

d--b 4y ago

Well these all suck. Obviously `@nest always` and `brackets` are the same in disguise, and are here cause they're conceptually cleaner. The problem with both of these is that they're unnecessarily verbose. Why not have a shorter token than `@nest` and something that doesn't want more indenting (like `{}`)? For example `\`? And then if you want to make things a little less verbose, just assume the first character is going to be `&` cause that's going to be 99% of use cases. And then you get something like this: foo { color: blah; \ h2 { font-weight: bold } \ h3 { font-weight: bolder } \ i > & { ... } } But no one ever listens to me!

LocalPCGuy 4y ago
Isn't that effectively what you get with the first option (with the `&` character)? You don't need `@nest` unless you want to embed the ampersand as anything other than the first character (which, I'll admit, is one of my major use cases). But given the prevalence of @ elements in CSS already (like @media for example), I'm ok learning/teaching @nest for those specific cases.

ImPleadThe5th 4y ago

Yeah I don't see whats wrong with the current css solution? Drilling down tags (the current implementation) just makes it more explicit in my opinion. I feel like nesting is going to take nice flat easy-to-read css and make it too complex and deep.

tolmasky 4y ago

If verbosity is the issue we're trying to solve for then it seems obvious that the answer is to simply use the nest emoji instead of "@nest". https://emojipedia.org/nest-with-eggs/ https://emojipedia.org/nest-with-eggs/

no_wizard 4y ago

I have a 4th idea for syntax. Use a similar syntax to media querys, where you use the `@nested` query with parentheses. Maybe too verbose? .has-nesting { @nested (> .nested) { /* rules */ } }

windows2020 4y ago

a { ... } a { ... } a b { ... } a > b { ... } is to is to a { a > { b { ... } b { ... } } } That's what I want. And it appears to fail correctly. The lookahead argument doesn't warrant poor syntax.

geophertz 4y ago

How about no? Why do we need to add further complexity into the already complex thing that are browsers? As the post mentions at the beginning, this can already be done with pre-processing. What do we gain by having more syntax sugar?

LocalPCGuy 4y ago
The ability to eliminate the need for pre-processors.

masswerk 4y ago

I'm in favor with option 1 (@nest, &). Reasoning: I do not see much sense in the use of additional brackets (option 3), since "&" already serves as a separator. I also do not see much sense in the use of the more verbose "@nest" (option 2), since conventional selector syntax uses single-character keywords already and there is no real parallel to things like "@media" or "@page" (as this isn't related to rendering and formats).

micromacrofoot 4y ago

Oh my, I much prefer @nest only even though it's verbose. The bracket method has good intentions, but a readability nightmare for me.

dsmmcken 4y ago

What I care about would be a SCSS to CSS nesting migration tool. Has anybody started work on that? 95% of my scss usage is simply nesting, variables, and color mix functions. Which means I could pretty much switch to a native solution when available. I don't really care which is chosen, I can learn to live with whatever.

amichal 4y ago

The cat is out of the bag but, one fear i have is how easy it is to abuse nested selectors this way. When I first was exposed to SCSS I also started seeing selectors like `.helpPage .faqSection .sidebar ul li` in lots of codebases I touched because it seems so neat and tidy in SCSS and made it easy to make that CMS generated list look just the way you want it to without injecting local class= attributes. Then 6 months later you want to restructure your containers and all your magic selectors work differently. Deep nesting is a trap those of us who have tried to maintain SCSS eventually learn and we use all sorts of naming conventions (e.g. BEM) to avoid it but for beginners having it there without tooling will probably mean we see even more of it in the wild at first. Edit: I still voted for `@nest` -- CCS is a pretty complex language for sure but I think it's terse expressiveness is why it's been successful.

LocalPCGuy 4y ago
I agree in regards to people abusing selectors, but I see that kind of code even without nesting. People don't understand (and IMO don't bother to learn) CSS specificity. Then they wonder why their CSS falls over.

butz 4y ago

Has Google finally learned something from the alert change debacle and is asking for developer feedback first?

rglover 4y ago

Thinking about this as someone who teaches web dev: this shouldn't happen. As others have mentioned, this goes just far-enough past the scope of CSS to just leave as a pre-processor feature. This will be an absolute nightmare for beginners and lead to a lot of messes/time wasted chasing bugs. If you can't get the as-is SCSS syntax natively without a bunch of hacks, it shouldn't be done (a bummer, as I'd love to have that natively). What could (should?) happen is codifying a pre-processor model into the standards track. Have a standard and then make some library the reference implementation.

aslilac 4y ago

I wish there was fourth option for “brackets but optional”. I like the brackets syntax, it’d be nice to omit them if you only have rules starting with &, similar to the “directive but optional” syntax.

wnevets 4y ago

I prefer the way & .class looks, its just like LESS

encryptluks2 4y ago

One thing CSS still can't do is to properly put multiple elements in a single flex or grid without having to wrap it with a div. I'm glad to see work being done on CSS but I somehow seem to frequently run into things CSS still can't do and there is always some proposal that isn't supported in both Chrome and Firefox.

andrewrothman 4y ago

It seems like the ideal approach would be "proving" syntax proposals by implementing them in a preprocessor first and then later trying to standardize the syntax if it gains traction. It sounds like there are technical reasons for why that didn't work for the case of SCSS-like nesting, which is disappointing but understandable... if that's the case I think the right approach is to take these new proposals and "go back to square one" (preprocessor) vs. "go straight to standardizing something new".

IYasha 4y ago

I see, chrome developers are, as usual, very busy people. No time to waste - CSS won't break itself! (@nest {sarcasm: red;} )

claar 4y ago

I vote for #4 - use SCSS syntax with bounded forward-lookahead. > CSS to date requires only a small, known amount of lookahead in its parsing, which allows for more efficient parsing algorithms, so unbounded lookahead is generally considered unacceptable among browser implementations of CSS. Then choose a bound! Make it big enough that it'll cover 99.9% of use cases, ignore any CSS rules beyond the bound with a console warning, and go on with life... This seems so obvious that I feel I must be overlooking something. Perhaps the bound would be so big, that when parsing multiple stylesheets in parallel the memory use would be unacceptable?

zelphirkalt 4y ago

*backets -> curly braces

coxmichael 4y ago

Can we not just have something like: a { &:hover {…} &:parent(.theme):hover {…} } No crazy selectors with an ampersand in the middle allowed, but a way to apply a parent or ancestor selector, a bit like :where() or :is(). There could be :in() for ancestors. No one needs this monstrosity: dialog { @nest html:has(&[open]) {…} }

toastal 4y ago
I'd be happy if they just left it here. You can only nest pseudo-classes and pseudo-selectors, and everything else either use your own tool to generate the CSS or just not not nest.

shaunxcode 4y ago

Use sexpressions?

arxpoetica 4y ago

I hate it. I hate it all. I voted for `@nest all` because I don't think it's a feature I will EVER use, so I wanted it to be dumb obvious that someone is using it by explicitly putting @nest in the code. That way if I encounter it in the wild, I'll be less likely to confuse it with SCSS nesting, for example.

MrPatan 4y ago

I guess I'm old and set in my ways, but I just don't want any of this. I never missed nesting. Don't Shadow DOM and components kind of make this not very important? I've mainly seen nesting used in huge multi-kloc scss files that applied to the whole site, which I find a bad idea anyway. I guess what I mean is: for small pieces of CSS it doesn't matter, and for huge nested structures.... you shouldn't do it

miragecraft 4y ago

I support @nest always with implicit &, so @nest .child {} equals @nest & .child {}