Hacker News Reader

Comment by slinger | Hacker News Reader

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

View on HN

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

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

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.

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

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

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.

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

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.

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.

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?

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.

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

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

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.

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

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

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

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

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

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?

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

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

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

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.

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

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.

Reply on news.ycombinator.com