[slinger]

> 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.

[Sesse__]

> 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.)

[lifthrasiir]

To elaborate why you need unlimited lookahead, consider the following:

    h1:has(+ p) { something: anything; } h1 { something: nothing; }
    everything: has(+ p) { something: anything; }; h1 { something: nothing; }

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.

[somishere]

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

[lifthrasiir]

Pretty much late edit: in the second line `: has` to be `:has` with no whitespace (as CSS parsers do care about whitespaces in some contexts).

[gaganyaan]

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?

[joeydi]

I agree that it's not really worth it, but the answer is not to choose a worse option. The answer is the just not implement it.

These options are bad, and CSS does not need this.

[alwillis]

> These options are bad, and CSS does not need this.

1. You don't have to use it if it doesn't seem useful to you.

2. Many developers (me included) use Sass and other preprocessors so they can use nesting; it's probably the single most popular feature of Sass.

3. CSS doesn't need nesting but a lot of developers want it, as it improves the developer experience for writing complex selectors.

[Beltalowda]

> 1. You don't have to use it if it doesn't seem useful to you.

Other people will use it and chances are you will have to deal with it sooner or later at $dayjob or whatnot.

[Gigachad]

The group in 3 can use SASS. At this point you should view CSS like assembly, convenience functions go at a higher level.

[alwillis]

> 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.

CSS still has to work in these environments.

[barnabee]

I hope web standards decisions are never made starting from the assumption that there's a build tool.

[somishere]

Possibly a stupid question. But is there a reason you couldn't include 2 engines? And require e.g. a doctype assertion?

[Klonoar]

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.

The line in the sand here is good.

[somishere]

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.

[1] https://news.ycombinator.com/item?id=32248837

[frivoal]

The reason why this cannot be done is documented in the csswg's informal FAQ: https://wiki.csswg.org/faq#versioning-css-fixing-design-mist...

[somishere]

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.

[wruza]

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.

[Sesse__]

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?

[somishere]

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.

[Sesse__]

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.

[somishere]

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.

[flappyeagle]

This is the correct answer. I hope this is where they land because all of the options they’ve presented are pretty awkward

[rtsil]

Option 5 already does this by prefixing the top-level selector with @nest.

It would be my choice of all 3, if SCSS-style nesting is not possible.

[runarberg]

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?

[Sesse__]

That was option 1, and it was voted out for being unneccessarily verbose.

[wnevets]

> stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.

That is my biggest take away from this whole thing. The SASS/LESS syntax is so much easier to read to me.

[culi]

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

[notpushkin]

Most of the time, yeah, but there's a corner case (example C from the article):

    a:hover {
      color: hotpink;
      :is(aside) & {
        color: red;
      }
    }

Here, you can't just use `aside &` as this starts with a letter and will confuse the parser. Hence, wrapping with `:is()` is requires.

[culi]

Tbh, if this sort of "nesting" is possible in Sass, I don't think I've ever used it...

Is it really necessary to support? I'd be cool with just simple nesting logic

[notpushkin]

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.

[culi]

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)

[wnevets]

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.