I prefer Option 3, but IMHO the "&" should be required in all cases. Having it present in some places and absent in others makes the resulting code less readable, more ambiguous, and generally harder to understand. I'd rather keep things simple and uniform, even if it costs extra keystrokes.
Also: it would allow things like ".a { &.b { x: y; } }" (which would be equivalent to ".a.b { x: y; }") to be clearly differentiated from ".a { & .b { x: y; } }" (which would be equivalent to ".a .b { x: y; }"). Just ".a { .b { x: y; } }" looks ambiguous between the two, since it doesn't "look like" a descendant selector.
I don't think it needs to be required, but I'd 100% include that in any linter or style guide I had for code.
For production code, I'd use it 100% of the time. For just quickly reorganizing some syntax around and copy/pasting things, I appreciate the shorthand version. I wouldn't use it in a codepen in most situations.
I very strongly agree. Mandatory & makes things much clearer, for a negligible cost. (And really, the curly braces, colon and semicolon are all mandatory (well, except the last semicolon of a ruleset), and alternative syntaxes with less punctuation like Sass’s have failed; the & is frankly more consistent than its absence.)
For a more technical justification: with optional &, priority is given (by brevity) to the descendant combinator, but what of other combinators? Do they require & or not? It could reasonably go either way. I haven’t read recent proposals, but am very familiar with CSS grammar, and I’m genuinely unsure.
parent {
/* This might or might not work. */
> child {
…
}
}
parent {
& > child {
…
}
}
This is another good point, particularly because (IMHO) people tend to overuse the descendant combinator in places where they should really use the child combinator instead.
Optional and being able to require it with e.g. a linter on a per-project basis seems better idea for me, since I'd strongly prefer not using & and for the vast majority of cases (as we learned from SASS) it's not needed.
Q for Smarter people than me with more experience: is it better to require stricter upstream and loosen the downstream (so would require &, and MyCSS framework could insert them where needed) or looser upstream and tighten local code with linters?
"be conservative in what you do, be liberal in what you accept from others" applies?
The problem is that "MyCSS framework" would not be a CSS framework, it'd be a full build system if it's incompatible, so that way no one would use the looser form. So if it's looser upstream, you can always tighten it more downstream in a fairly seamless and optional way, while the opposite is not really true.
I don't know, I have been using SASS/LESS for a while and I almost never use the & because 95% of the time, I am talking about a descendant when I use nesting. I think it would be very easy to accidentally typo or miss in a review the difference between "& .sub-class" and "&.sub-class."
The point is that if & cannot consistently serve as a marker, then it shouldn't be one. Just add a different piece of syntax that always starts a nested rule and clearly disambiguates it and retain & solely to designate the parent.
I agree completely, and having followed this since it was a pipe dream, I’m actually sad that the machine parsing and unambiguous human readability convergence lasted so long to hold this up only to fall apart as it becomes a real possibility.
Not a requirement because it’s not in the spec or because developers don’t need it? If the former, the proposal is to make it a requirement. After CSS grid, CSS nesting is probably the most requested feature of CSS for as long as I can remember for web devs. I only use sass these days for nesting and it would be nice if I didn’t need that extra dependency.
I've stopped using preprocessor for years now. Almost everything I need is now in the spec or solved ‘good enough’ through a naming scheme. IMO, a preprocessor is a lot of complexity for little gain currently.
Eh. I kinda hate writing separate selectors just for a `:hover`
I agree CSS has come a long way. Nested CSS is the one thing I'm waiting for before I completely abandon preprocessors.
Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. Sure, better practices could usually make this unnecessary, but there's definitely valid situations for it. If you add up all the extra kb across millions of sites, and all the extra savings minifiers would be able to achieve with this syntax, I'd bet it starts to add up at a certain point
I was sad to see it left out of 2022-interop, but it's definitely the biggest feature I'm waiting for
> I was sad to see it left out of 2022-interop, but it's definitely the biggest feature I'm waiting for
My understanding is the features for Interop were chosen because there wasn't good interoperability between browsers for them.
With CSS Nesting, once the spec (and the syntax) is finalized, it's going to work the same in all browser engines; hopefully it'll go smoothly and we won't need CSS Nesting be part of Interop 2023.
20 bytes per rule. While not a fan of the syntax[1], there’s the advantage when reading of seeing that rules are explicitly nested versus doing string parsing of rule definitions.
[1] In particular the significant space char difference between &. And & .
At minimum, you'll likely have different effects for links than for buttons.
Component-centered design is very common so the styles for each component that would benefit from :hover may have its own variation on it, for the color differences if nothing else.
:hover is not the only interaction pseudo-class, :focus and :active can also be nested.
The biggest feature I miss from Sass is the indented syntax (though SugarSS does that better since it has multiline support); for now I make due even if semicolons and brackets add noise. There's still a use case for Sass if you need to build a CSS library and the loops and stuff is useful, but for general, contemporary CSS authoring, wanting to reach for loops and these extra features is a sign of a smell more so than not.
> The biggest feature I miss from Sass is the indented syntax (though SugarSS does that better since it has multiline support); for now I make do even if semicolons and brackets add noise.
Yes! The indented syntax is why I’ve stuck with Sass, Stylus and SugarSS for all these years for the same reasons you stated.
But… I decided it was worth going back to plain CSS due to CSS Nesting and to simply my tooling.
I do wonder whether "no nesting" should've been an option in the poll. Not because I necessarily think it's the right option, but it might be: if this gets added to CSS, but people keep using other tools for easier nesting, then we're stuck with that implementation nonetheless.
I try not to use preprocessors or bundlers/build tools for simple stuff so the addition of features like this to the base CSS language is something I look forward to.
Preprocessors aren't always available though. For example, I almost never have access to one, developing with MediaWiki (there is an extension that makes it available but most of the wiki farms I've worked for have not had it installed).
> If CSS can’t match or improve on the obvious syntax used by sass then they should not implement it.
And this is the problem. For so long there was a technical limitation because parsing complexity, then there suddenly wasn’t a limitation anymore and the existing syntax wasn’t good enough anymore so we’re shooting the moon.
I agree, all of the options are confusing. The only seemingly viable option is close to Sass, but it should just be strict and stop introducing more ambiguity to the grammar which is already absurdly complex.
For sake, Stylus doesn't even require colons and semicolons with plenty more features that was invented more than a decade ago and CSS is still trying to sort out things that was solved in 2010 in worse ways in 2022?
This is beyond comprehensible.
I guess I can never let go of preprocessors.
> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work.
I wish browser vendors could work around this limitation and stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.
> I wish browser vendors could work around this limitation and stick to Sass syntax.
FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web will become ever so slightly slower. And you cannot ever go back after making that choice. Is it really worth it for the few unusual cases that require workarounds, in an already not-super-common feature?
(Disclaimer: I wrote Chromium's CSS nesting support. It currently implements option 3.)
Syntactically speaking these two lines are equivalent except for a single semicolon; the differing first token doesn't change anything about that. And you can absolutely add a custom element that looks like a property name to blur a line further. So in order to see if the first block is a rule or a property, you absolutely have to read up to the first `;`, excluding nested braces and alikes.
That said, the main problem is that the property syntax is overly forgiving, not that the nested rule syntax is problematic. Something akin to JS `use strict` should be able to restrict the property syntax enough to allow the nested rule syntax without unlimited lookahead.
First up, anything starting with a .#* is a selector. Secondly, if you're selective about valid tokens then how many tokens are both a valid selector and property name? Probably custom only? And the number of times you'd find a pseudo selector on one of these? We're rapidly approaching extreme edge case territory here.
Also, looking at your second line: I would say the second part (starting at the semicolon before the h1), is invalidated by the semicolon. No need to lookahead or read up to the semicolon. The first part would always be evaluated first, up to the closing curly bracket. The second part would fail at the first character. I'm looking at this on a phone so maybe I've misread?
Edit: I should add, I'm not disagreeing with your point (I don't think!), just emphasising it
Do you have any numbers on that? On a modern computer, I'm having trouble believing that the time difference would be noticeable to a human. Seems like parsing even a few megs of CSS would be measurable in milliseconds?
> At this point you should view CSS like assembly, convenience functions go at a higher level.
CSS isn't assembly; it's higher level than that. I get why some want to treat it like a low-level language but it's not that, which is pretty obvious if developers take the time to understand CSS at a deeper level than just something a preprocessor spits out.
Also, CSS has to work in environments where using a preprocessor isn't an option—it's not just for glossy VC-backed websites. A preprocessor and all of the other tooling front-end developers use aren't an option for the vast majority of content management systems and wikis for example.
Because it's the same result as if you just included the slower one, since there's mindshare for the SASS variant already - it'll just become defacto standard, and slow down the web.
I guess the idea would be something along the lines of a 'strict' tag, to identify a shift to modern syntax with stricter rules around parsing, that ensures an infinite lookahead wouldn't be required for e.g. pseudos vs properties.
I put together a regex last time this was discussed [1] (which obviously completely alleviates all concerns): https://regex101.com/r/aOc2Pz/1
But seriously, syntax evolutions happen. If there's an issue with parsing garbage CSS why not just let that garbage run slowly, and re-optimise for the rest, prioritising for form and function.
The documented reasoning and references do not make any sense. Older browsers are going to choke on newer syntax regardless. This is an ongoing issue in the JS domain that is managed reasonably well via e.g. polyfills, tooling and rapid release. Often with code bloat initially, sure, but the browsers catch up. The days of "oldIE" are long gone.
The point of the declaration is to tell the browsers that can handle the syntax to handle it. Another method could be to use a new linking method. Regardless, the language would still gracefully degrade as only the newer syntax would require strict rules in place.
Please explain it to me if I am completely missing the point.
This mindshare is mostly among end developers. Big frameworks will still compete in performance (iff it really that matters, the numbers are kept in secret for some “full-stop” reason) and use preprocessing and boil-down minification as they are now.
The implied impact is based on a wrong assumption and unpublished effects.
If nothing else, it would strongly increase maintenance and testing costs. You also have the usual problems of cut-and-paste between examples and stylesheets not necessarily working as you'd expect. Then there's the subtle issue like how you'd serialize such things from CSSOM (JavaScript); which parser mode would you use? How would you serialize something “unsupported” in one mode that was created by CSSOM? Which mode would inline style attributes use?
Understood. But if the idea was for a 'strict' syntax? i.e. in order to make use of newer syntax rules, CSS would need to declare itself as such and be formatted per spec (and would fail to parse otherwise, same as now), negating the need for "infinite lookaheads" per the explainer. So it's more like a switch statement than multiple engines. CSSOM is straightforward this way, you're dealing with strict by default. Inline styles the same.
It's not clear at all what that strict syntax would look like that would disambiguate with less lookahead. The fundamental problem is that colon is used both for declarations and in (pseudo-)selectors, not that people are somehow inventing corner-case CSS that nobody actually writes and we can just outlaw in a spec change.
The only change I can really think of would be requiring space after the colon for declarations (i.e. “color:red” is disallowed, it must be “color: red”), but that's much more than a strict mode, that's something that invalidates millions and millions of perfectly valid web pages and introduces a much larger whitespace sensitivity than today.
The difference isn't the separator, it is the suffix. Strict designation would afford that either properties be signed off with a semi-colon on the same line (or just a newline). Alternatively you could go the other way and enforce selector signoff with a comma or a bracket on the same line. No strict, no nesting /newfangled wizardy.
This allows for graceful degradation.
My point about corner cases is that there is very, very limited use of pseudo selectors, relatively speaking. Let alone pseudo selection where the selector is based on an element and not a class, or ID, or something else easily differentiable from a property. Which is to say, they are the corner case.
Once you start looking at the suffix to disambiguate what the first token means, you're already in the more-than-one-token lookahead land, which is what we're trying to avoid in the first place.
CSS property declarations already need to be signed off with a semicolon on the same line. If not, the entire declaration is ignored (this is specified in the CSS standard, and if you don't implement it correctly, you will break real web pages).
I'm sorry but I thought the challenge as described was one of "infinite lookahead"? Similarly, the csswg profer "graceful degradation" as the reason why a declaration isn't workable. But this solution clearly doesn't require infinite lookahead. It also degrades gracefully.
In fact lookahead isn't needed at all, except in (exceptionally) rare cases. Is the problem that the parsers are incapable of using any smarts beyond what is already provided?
Am I missing something?
Aside: Good point on the semicolon! I think in the previous discussion someone was making the point that parsers are exceptionally flexible/forgiving re. weird and wonderful line break and spacing combos. I wasn't sure about the status of semicolon usage. Idea of strict would just be to put an end to that.
Edit: and hey, apologies for labouring the point on this. But I am genuinely interested. I feel like these conversations just always end up in "you wouldn't understand" territory.
> But this solution clearly doesn't require infinite lookahead.
It clearly does? There can be an infinite number of tokens before you see the semicolon and know what you're parsing. The page contains examples of this, or you can dig into those bug threads.
> In fact lookahead isn't needed at all, except in (exceptionally) rare cases.
“You don't need to support lookahead, except sometimes” really means “you need to support lookahead”. And that changes how your parser and tokenizer has to work (in particular, you need to be capable of saving a potentially infinite amount of tokens in case you need to rewind). You don't get around that by saying it's rare.
Yes, you need to support lookahead. But not unbounded. There are so many efficient ways to solve this problem. But computer says no?
Forget the idea that the tokeniser could place markers on semicolons / curly brackets to bound any future lookaheads. Why couldn't you just look one token ahead and analyse the potential pseudo-class/property. Pseudo-classes are clearly defined. There are about 50 of them. AFAIK none of them clash with property values. Keep it this way. If it's not a valid pseudo it's either an invalid selector or a property. Then you're just analysing the equivalent of a property value anyway.
---
Of course the above logic is flawed. I'm really just trying to tease out some useful information other than "can't be done".
I think the main challenge with this discussion is that the limitations of the parsers are not clear, at least outside circles directly working with them. Not only that, the explanations of why certain cases won't work are provided without the proper context needed to understand.
From what I understand tokenisation is dumb, it basically just spits out words. Without nesting it is straightforward for a parser to iterate over these tokens one by one, distinguishing between selectors and properties, based on prior context. Of course parsers could look ahead, but by design they don't, because efficiency.
The arguments for breaking the defacto nesting syntax (i.e. scss) seem to lie in the fact that the rules of the past must lie within the rules of the future, because graceful degradation.
Option C. - the most popular option, and also the most true to scss - while pragmatic in it's approach, is still shoehorning new into old.
I'm sure most agree that unbounded lookahead is probably not workable. But to make the argument that parsers can never look ahead, can never improve, seems ideological, if not ridiculous.
What happened to the rule where if the nested selector doesn’t start with & then an explicit @nest is required? Doesn’t that fix the unlimited look-ahead?
I don't really get how tbh. Isn't Option 3 the exact same thing as Sass except the "&" is required in a few more places than it is in Sass? It's also optional in Sass so I already write that way (always using the "&") personally
It is definitely possible, just with a more complicated (and slow) parser than what browsers use now – there's been some discussion in this thread.
As for whether it's necessary – eh, it's neat and might be useful sometimes but it's not a big deal I think. Personally, I remember a couple instances when I needed to override a few properties depending on context and it would be helpful, but `&:hover` is so much more useful.
Right and now that we have (or will, soon enough) `:has`, I really don't think it's worth mucking up the potentially very simple and sweet nesting syntax to support something that's probably usually a bad practice anyways (though obviously I'm speaking from a place of little experience using this)
I never use & when I am only nesting. So when I am skimming code quickly and I see an & I immediately know there is something else happening besides a nesting, for example &:hover.
This is probably something I can unlearn but until then it is very jarring to see & everywhere.
I'm a bit confused about the constant mention of option 3 in this article, because it seems to match none of the actual options from the original poll. The original poll offered three options:
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.
Isn't this what Sass does? Option 3 seems to me to be exactly Sass nesting except the "&" is required in more places than it is in Sass. I personally love the "&" and already write my Sass that way anytime I nest
Wow. I’m really surprised so many people have voted for option 3 so far. Option 5 feels much more in line with the rest of the other proposals and features in CSS, and option 3 introduces at least one quirk we’ll have to internalize and teach to everyone forever. Those suck. I have to teach those kinds of things to juniors until my throat is sore some days.
I don’t have much of substance to say about option 4 other than that it just feels… gross. I’m sorry, but those butterfly brackets are really extra.
Circling back, I think my preference for option 5 is that I personally moved away from nesting with preprocessors after watching too many developers create specificity bombs in their CSS from selectors nested 4 or 5 layers deep. I think it makes sense for this syntax to have a clear, distinct weight to it. CSS should be meant to be read just like all other code.
Finally, and I won’t spend too much time on this because I’m not trying to be a detractor, I’m not sure this is really high up on my wishlist anymore. Component-based design has changed a lot about the way I write CSS. I’ve found that I write a lot fewer highly-specific selectors these days, and I never have to bother with heavy id/class syntax conventions like BEM anymore for things to be easy to understand either. Those two things alone were big, dangerous motivators for me to use or encounter nesting. Anyway, I voted for option 5.
The web has given me an amazing career and life (that I feel is still very much only getting started). I’m always happy to contribute when I can.
That being said, I wish I could better articulate my opposition to No. 4. I think it’s because it immediately strikes me as a typo, like if someone was editing some CSS, deleted a selector and then forgot to write a new one back in before committing their work. Others seem to suggest that formatting addresses this, but I’m uncomfortable with that because it’s very subjective.
>Others seem to suggest that formatting addresses this,
I feel the same way about python. To me, indentations and spaces are much more for human legibility than the parser's. Something in my brain says that symbols like curly/square braces designate code blocks much more succinctly than white spaces.
However, for someone that started in a language that used white spaces vs symbols, I get how they would feel the opposite.
Option 5 is more structured but Option 3 is faster for a person to work with. I don't think either approach is necessarily more "long term" than the other unless there is another tradeoff I'm missing neither is an invalid thing to optimize the long term for.
Having to go back and modify the existing non-nested lines when you just want to add a nested declaration seems like a large source of "oh damn it" errors and twiddling when you are progressively building/testing styling. The same with wanting to keep default and pseudo-class attributes close to each other for human convenience.
It’s a fair question. Almost anything can be a weapon if you try hard enough. “Prevent” is perhaps too strong a verb. I’d settle for discourage or maybe even just contextualize. I get the impression that by explicitly declaring each nesting context with “@nest”, the effort required to type those extra characters might center the meaning more around code organization, maybe? If nothing else, it helps the eye track better in deeper trees.
In my experience, when I’ve committed this sin or watched others do so, it’s often because some styles that have already been written need to be updated. Writing CSS is really easy. Nesting makes it even easier. The thing I and I think most people struggle with is organizing it. I think nested styles encourage people to go out in search of a defined scope to ammend moreso than it does to encourage them to write a new one (or selector). It’s easy to see a class you’d need, skip a couple levels down the tree and then get excited when you add just that one element or class you think you need and style accordingly… Only to find out later that you created a difficult to debug style bug that pervades the whole site. My hope is that it would encourage people to think twice before going beyond that second or third level and maybe encourage them to create a new style block instead. I’m also not terribly concerned length or effort these days because of tab completion.
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.
Same. 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.
I 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.
I 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.
For me it's the opposite. I find the nesting far easier to parse, especially when deeply nested. One thing to consider is what the average dev uses - looking at the 2021 state of css ( https://2021.stateofcss.com/en-US/technologies/pre-post-proc... ), SASS was used by 90% of responders, and of those 84% of them were satisfied with it.
There's a strong argument to be made that nesting is the standard way to write CSS these days (at least among the demographic that responded).
that's great, but sometimes when I start vanilla side projects I like to take a CSS Zen Garden approach to things. That's harder to do the more tightly you couple your HTML and your CSS
The stylesheets for CSS Zen Garden examples are more tightly coupled to the HTML than any other CSS I've ever seen in my life. They literally have no use against any other block of HTML than that one page.
One could be forgiven for thinking any committee depraved enough to enumerate the options sequentially as 5, 4, or 3, moreover where option 3 is not even the same as the prior option 3, has implicitly renounced any standing to be offering solutions in re. developer ergonomics.
I actually like Option 3 the best even more than sass syntax.
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.
It feels weird that the CSS WG does a popular vote for a different syntax implementing the same feature, something that an expert opinion should weigh way more then popular demand. But at the same time TC39 picked an archaic version of the pipeline operator (|> https://github.com/tc39/proposal-pipeline-operator) despite a clear demand from the community to pick a functional one.
Perhaps the two committees should learn a bit from each other.
The version they’re picking is the fast pipe from OCaml, and the only pipe in ReScript. It works much better for type inference, and avoids the extra allocations the FP pipe usually incurs
Or play a similar weird trick to the original option 3 and only require :where(...)/:nest(...) for selectors that begin with a letter. But that starts to look a lot like option 3. Especially if you always require &, because then & can be used to disambiguate the child:pseudo parsing problem.
I'm not familiar with the past discussion of any of this, though.
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.
One big advantage of option 3 is that it allows for putting properties and nested selectors in any order, rather than segregating them in different groups. This is already possible in Sass and I do it all the time. For example:
> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work.
I may be in a minority, but I think that what-you-write-is-what-your-browser-parses should be ditched as a norm. There should simply be an efficient (binary) format that is treated as an irrelevant implementation detail.
What is even the problem? People use preprocessors, poly-fills, hot-reloading, etc anyway. It isn't 1990s.
> What is even the problem? People use preprocessors, poly-fills, hot-reloading, etc anyway. It isn't 1990s.
All of this tooling is used because of missing CSS features for the most part.
The web browser's ethos is to be a viewing and authoring environment; from Netscape Navigator on, browsers have enabled its users to write HTML and later, CSS.
For that to continue, browsers we can't have web authoring that's dependent on preprocessors, etc.
Another way to think about it: in an alternate universe where CSS had all of its current features like custom properties (a.k.a. CSS variables), nesting and most of the other modern features, there would be no Sass because we wouldn't have needed it.
In our current reality, CSS is maturing to the point where the work-arounds we implemented aren't going to needed for much longer. We can do that without breaking how the web has always worked.
Everything is still going to be tree-shaken, minified and mangled before being transferred to the client; no matter how much bells and whistles are added to web languages. Why not just make it decoupled and efficient? Compiling code isn't a radical idea.
As pointed out in the article, the nesting syntax has to work in every setting that CSS works in today and has always worked in—from a hobbyist working alone on a side project to teams working on huge code bases and everything in between.
Because of the universality of the web, anyone from a kid in a developing country with a netbook and a text editor to teams at Fortune 500 companies need to be able to author CSS.
It's a non-starter to require all kinds of tooling—preprocessors, compilers, task runners, packagers, etc. to create web content. You can use these tools if it makes sense for a particular situation but it should always be optional.
BTW, browsers already use Just In Time compilers [1] to render CSS as efficiently as possible; all of the tooling you mentioned is mostly to reduce the size of CSS payloads over a network. Regardless if you minify CSS or not, its rendering speed isn't going to change.
With these tools, there's no compiling happening anyway, just transforming one text format (Sass) to another text format CSS. It's not like WebAssembly where code is compiled into a byte-code format that runs in a virtual machine.
> As pointed out in the article, the nesting syntax has to work in every setting that CSS works in today and has always worked in—from a hobbyist working alone on a side project to teams working on huge code bases and everything in between.
Yeah, and I’m saying it shouldn’t work anywhere at all.
> Because of the universality of the web, anyone from a kid in a developing country with a netbook and a text editor to teams at Fortune 500 companies need to be able to author CSS.
Compiling messy unoptimized code into efficient code is somehow bad for kids with netbooks? I don’t follow.
> It's a non-starter to require all kinds of tooling—preprocessors, compilers, task runners, packagers, etc. to create web content. You can use these tools if it makes sense for a particular situation but it should always be optional.
Why? So the whole modern world should be stuck with outdated decisions from 1980s and be horribly inefficient because there is one kid in Djibouti who can’t download VSCode and learn to click F5 to compile things?
> BTW, browsers already use Just In Time compilers [1] to render CSS as efficiently as possible; all of the tooling you mentioned is mostly to reduce the size of CSS payloads over a network. Regardless if you minify CSS or not, its rendering speed isn't going to change.
Yet they are still unable to implement Sass syntax. So why not just get rid of this fundamental limitation that just makes no sense and that barely made sense even 10 years ago?
Nesting promotes bad CSS which exacerbates the problems people encounter elsewhere in CSS (like excessive specificity).
Nesting discourages paying attention to the global scope of the language and we already have many solutions to that problem for those of us who like to pretend the global scope isn't there.
Nesting grossly accentuates up front write-time benefits, whilst degrading the later read-time experience, actually making long term support harder.
I like option 3 the best, but what I'd really prefer would be block-scoped css blocks that could optionally be scoped just to children of the parent tag.
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 <style scoped> 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.
Yes, the latter. At least Chromium-based browsers support it behind a flag (ie., you can't use it on the web yet, but you can experiment with it and file feedback). I don't know if Firefox does, too, but they very well might.
Sharp observers will notice that flattened declarations look like path expressions.
While CSS selectors are nice, path expressions enable concise drill down to precise modifications (overrides).
For future, every programming language should have intrinsic path expressions. Basically a useful, usable, legible version of LINQ.
--
PS- I really don't get the '&' ampersand. It's like a reference?
"foo.bar { ... }" is sugar for the expanded "foo { bar { ... }}". Makes sense. (No ampersand required.)
But "foo { bar & { ... }}" being the same as "bar foo { ... }" breaks my brain. What's the use case for reversing the parent-child relationship, contrary to the lexical order?
So far, most of the responses are pretty underwhelming.
It's like that exercise middle school teachers sometimes do. They had out a worksheet where the directions tells the students to put their pencil down and do nothing. The rest of the worksheet is a series of questions or whatever.
80% of the students don't read the directions and start filling out the worksheet while the 20% who did read them are just sitting there.
That's what the feedback to an official CSS Working Group question has been like so far—people responding without having read the article; otherwise, they would know that…
1. Because of the way browsers work, the Sass syntax isn't an option—full stop.
The person who implemented Chromium's nesting support explains in the thread [1] why Sass's syntax is not an option. IMHO trying to revive a discussion about wanting the Sass syntax at this point is unproductive to say the least.
I've been using Sass and Stylus pretty much exclusively for a bunch of years—I get it. But that ship has sailed a long time ago, so let's not spend a lot of time on something that's not going to happen.
2. Perhaps before you respond, you should get up to speed on the issues at hand? There are links in the article you may want to read before you respond.
3. Here's what's arguably the most important thing to consider:
Which is best for the future of CSS? When people write CSS thirty years from
now — long after today’s habits and expectations are completely forgotten,
when future generations have never heard of Sass — which option will make writing
this language easy and elegant?
This requires thinking beyond your personal preferences or what you and your team have been doing for the past 10 years. It's about what's best the future of CSS for the long term.
We weren't writing Sass 20 years ago (Sass made its appearance in 2006) and we won't be writing Sass 20 years from now [2].
If you think about it, nesting is one of the top reasons why devs use Sass today; once CSS nesting is enabled in all three browser engines, a lot of devs won't feel the need to keep using Sass for every project.
I know there are other features and workflows that Sass/Less/Stylus enable but as far as authoring stylesheets goes, nesting is huge.
This isn't like the old days when it took years before you could use new CSS in production—Chrome already has an implementation (I've used it) and once there's agreement on the syntax, I can't see why Apple, Google and Mozilla wouldn't be able to ship it Q1 2023.
So think about what's best for CSS and the web based on where things are headed—this isn't about you. Okay, it's not entirely about you and your team; but it's mostly about us— current and future web developers.
We're going to need to live with this choice for many years to come.
[2]: To be pedantic for a second (this is Hacker News after all ;-)), yes, someone will have to work on some legacy codebase 20 years from now that has thousands of lines of Sass… I get that. But we're getting close to a point in time where the vast majority of new web projects will not need to use Sass.
You browser developers seem to already decided on it, so why asking at all. This “help us to choose but stay silent if you don’t like it” is pointless. I am well-informed on most of these nuances and don’t like any of these options. Will stick with sass unless forced to use some of that, I don’t care which you end up with.
My opinion is: provide a slow parser for my kilobytes of “style.kbcss” and do whatever you want with minified bootstrap megabytes and such. If you don’t feel like counting this opinion, fine. Build pipelines or makefile-likes or just a caching middleware is not a deal big enough to make drama out of it.
I see why you may find uninformed opinions irritating, but the only constructive thing here is to make your comment softer and put it into the header of that site. People may not visit links, may not understand what/why or may (surprise) not care about implications. If you care to make a poll that excludes some opinions in advance, prepare the auditory correctly.
This is more vitriol than necessary. The comment you linked to says the bad syntax choices presented in the article would allow for an easier parser implementation, but doesn't really expand on that or give any numbers. If someone thinks that the better syntax is worth a likely imperceptible increase in parsing time, that's hardly worth this harsh comment.
I read the whole thing. And I don’t care if it doesn’t work or what excuses they make.
If it’s not gonna be similar to any existing implementation for doing css then don’t bother doing it.
The last thing we need is a shit version of nesting. The syntax we have now is good, it’s what we know, it works. There’s no need for stupid filler syntax to work around scenarios. I.e prefixing with @nest.
I'd say they should avoid bloating CSS, keep Sass style and just use type='text/sass' or type='text/css-nested' in the style tag, but it seems that attribute is depreciated... why is that?
Could a backwards parser work? With the Sass syntax I think doing the parsing backwards can be made without lookahead. Probably it has other issues though...
I want it to work the way Stylus works, because Stylus syntax is better (fight me), but I will accept Sass and its unnecessary braces as an improvement over current CSS for sure!
I think the question that's not answered clearly is: why can Sass parse it, but browsers can't?
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"?
I may be wrong, but I think it's a matter of complexity and speed. An efficient parser knows exactly what it is reading just by checking the next following word (token) and can act before it even reads the whole thing. Sass uses an "infinite lookahead" algorithm that makes it way slower (maybe doesn't matter for 1 file, it does for hundreds). With sass the parsing is made only when compiling the app, so it can afford the extra processing. On browsers, specially mobile, it can become a problem if you need to do it on all css of all pages.
An example that I think it's easy to understand: suppose you are reading a csv string of numbers that can be in base 10 or base 2.
Option a is something like "32, 101b, 101" (aka binary numbers have a "b" suffix, decimal numbers don't)
Option b is the same but the "b" is a prefix "32, b101, 101"
Now think that you can only "see" one character at a time, so you see "3", then "2", then "," and so on. Which of the two options is more efficient to parse?
The answer is option b. With option a you could read a sequence of millions of 1/0 digits but you don't know if it's binary or decimal until you read the final "b" or a "," (or end of file) so you can't do anything but remember all the digits until the end, when you can finally do something with the number. With option b you know in advance if it's going to be decimal or integer (whether you receive a "b" or directly a digit) so you can do all the optimizations right away before even start reading the number!
It's not a matter of whether it can be done or not (of course it can) but the complexity and slowness it can become.
> I think the question that's not answered clearly is: why can Sass parse it, but browsers can't?
I'm tired but here goes…
Parsing the proposed syntax isn't the real problem; it's parsing plus executing the selectors. Long story short: CSS is programming language that uses a JIT compiler to render CSS.
Sass doesn't run anything; it just transforms one text format into another text format; it's the browser runs the CSS.
Compared to what's required for CSS to run inside of a browser, interface with HTML, JavaScript and SVG (for starters), the Sass parser is trivial in comparison.
> Does this all just boil down to "we don't want to have the work of rewritting the CSS parser"?
Seriously, that's a non-starter for a code base the size and complexity of a browser engine. Not to mention it could mean throwing away years of work on these browser engines.
It's way too late for that… Chrome already has option 3 implemented; to rewrite something would delay this by… a few months? Maybe a year?
Think about it: should Apple, Google, Mozilla, Microsoft, Igalia rewrite code that's already running successfully for billions of users to accommodate whiney developers, many of whom are going to keep using Sass anyway, no matter what they do?
I doubt any of us, if we were leading these teams, would think rewriting major portions of the browser engines makes any kind of sense at this point.
SASS only really cares about CSS compatibility with valid CSS, and won’t compile invalid CSS
Browsers handle CSS in a way that invalid CSS is ignored. This way, when you add new syntax to CSS, older parsers will ignore just the parts it doesn’t understand, and most (or all of the developer is careful) of the page will will be styled correctly
So in short, browsers have to make invalid CSS work too
It does not matter if the browser can’t do it. Make it do it.
There’s no point in supporting nesting if the solution is worse than the options we have right now.
The vast majority of people would rather stick with preprocessors than deal with shit syntax.
If they implement a shitty syntax because of browser limitations they don’t want to fix. People will just use pre processors.
So it’s not about reading or not reading the article. It’s the fact that the options are shit and unless they do syntax similar to what we do now they should abandon trying to support nesting.
Of course option 3 but make "&" required.
And ":is(aside) &" is ugly, should be just "aside &". Yes, it starts with letter, but it's the only way to be not ugly.
Personally, I don't need the ability to place '&' anywhere. Just extending selectors at the end is sufficient. So I would greatly prefer a SASS-like syntax that they excluded.
what will nesting do to the cascade rules - I suppose that
.foo {
& .bar {
color: blue;
}
}
will have the same precedence rules as
.foo .bar {
color: blue;
}
in which case it is probably best to avoid the usage in most cases.
Given CSS variables, container queries and various other developments nesting seems like a bad way to organize your CSS.
on edit: to clarify my experience with sass is that people nest overly much, creating very complicated precedence situation that then later they can't figure out why their bar class is blue.
I feel like option 4 is about the only one with somewhat sane indentation. At least in conveys what level the nesting is on for the root nesting element.
I like the idea of using newlines to alleviate some syntactical issues. Here is what I came up with after experimenting with option 4:
.foo
{ color: red
;}{ .bar
{ color: blue
;} p
{ color: yellow
;}
}
If you make punctuation dimmer in your editor, it becomes a nicely aligned structure, also a toplevel ;} denotes a beginning of a nesting block, it’s like “hey look here as well ;}” and searchable with /^;}{.
> I want browsers to have first class Sass support.
We don't want that.
For example, CSS Custom Properties (CSS variables) are far more powerful than Sass variables. Plus you'd have two different implementations for how variables work—CSS variables work with the cascade but Sass variables don't. You can't have two fundamentally different methods for variables. That's a non-starter.
Pretty much all of the good stuff from preprocessors is going to be implemented in CSS (including conditional statements) relatively soon; we're just not there yet. But CSS Nesting is an important first step.
> Statistically, we do. Sass won the precprocessor wars and nearly every developer prefer SCSS variables over the var(--oh-god) that is CSS syntax.
This isn't about which preprocessor is the most popular; it's about the syntax that's going to be used for CSS that we're going to have to live with for a long time.
Look, best practices come and go. Table-based layouts, 960 grid [4], Dreamweaver, special hacks for IE6—we don't do those things any more. With all of the enhancements that have already been added to CSS (CSS Grid, Flexbox, Container Queries, :has() parent selector) and the ones coming—CSS nesting, style queries, conditional, new/better color spaces—using Sass will seem as old-school as including jQuery in every project in a few years.
To quote Denzel Washington's character in the movie Training Day: "We don't roll that way any more." [5]
If you want to go on using Sass, then nothing changes for you; you can even use custom properties in your Sass files. It's not an all or nothing situation.
> How are they more powerful? Does that offset their downside?
Seriously?
There's no functional downside compared to the alternative. The syntax isn't bad once you understand what's going on, but that's subjective anyway. Even if you don't love the syntax, the functionality they enable for developers more than makes up for that.
Sass variables are just static placeholders for values; they're just a step above doing a search and replace in an editor. Very handy when Sass was developed 16 years ago, but very limiting today.
The real question can the dynamic web experiences people come to expect be done only using Sass variables? Are taking full advantage of everything the web platform has to offer by only using Sass variables? The answer is no in both cases.
- they're not part of the DOM and they can't be accessed via JavaScript
- they can't be changed at runtime, such as responding to media queries or other state changes
- can't be used for passing values to and from web components
There are dozens of articles about why custom properties are superior to preprocessor variables:
That preprocessor variables are compiled out of existence is a feature. There are certainly situations where Custom Properties are useful, but if you don’t need that power, then using something simpler or inlining them out of existence produces results that are faster to run, use less memory, and are almost always smaller to ship.
If you open the article you will find this as the 4th paragraph:
> So, a lengthy discussion began about what to do instead. Earlier this summer, the CSSWG debated between Option 1, Option 2 and Option 3. Of those, Option 3 won. Since then, two more options have been proposed, Option 4 and Option 5. If you remember various details discussed across 53+ issues, put all of those older ideas aside. At this point, we are only debating between Option 3, 4 and 5, as described in this article through the set of examples below.
Also: it would allow things like ".a { &.b { x: y; } }" (which would be equivalent to ".a.b { x: y; }") to be clearly differentiated from ".a { & .b { x: y; } }" (which would be equivalent to ".a .b { x: y; }"). Just ".a { .b { x: y; } }" looks ambiguous between the two, since it doesn't "look like" a descendant selector.