5 ms·

I read the page's reasoning for why everything can't be directly nested, but I still don't get it. Why is an "unbounded lookahead" an issue?

• wlib 5y ago
  Keeping a tiny bounded lookahead is essential for the extremely fast and memory-efficient parsing that browsers want for CSS. Sass, less, &c. don't really have to care about that, and they have the benefit of also being able to completely trust that the user won't give pathological inputs - unlike browsers on the web. Also, I think the standards bodies want to minimize their changes in general, to keep the door open for unexpected changes later.
  • adamrezich 5y ago
    I'm no expert in parsing but my gut tells me there's no way this can actually be a performance concern as much as a implementation complexity concern
    • klodolph 5y ago
      Right... you don't want to force everyone to make significant changes to their parsers. If you are writing a C or C++ parser, you know up-front that there is lots of funny business in the language syntax and can plan your parser accordingly. If you are writing parser for something a bit more sane, like Java or CSS, then you can choose a much simpler architecture for your parser. Part of this means that if, say, your language is LL(1) or something like that, you will want to keep future versions of the language LL(1). This can put you in a bit of a tight spot sometimes, when you're making backwards-compatible changes.
• klodolph 5y ago
  The amount of lookahead necessary dictates what algorithms you can use for parsing. If you go from 1-token lookahead to unbounded lookahead, you might force a lot of people to rewrite their parsers or make major changes (because they would have to use different algorithms). This would mean that a lot of CSS parser would simply not adopt the new syntax, at least not in a timely fashion. If you keep 1-token lookahead, existing CSS parsers can just drop this in.
• zeroimpl 5y ago
  The term "unbounded" seems a bit strange to me too. At worst you only need to lookahead until the next ; or { to figure out if it's a property or a nested selector. I guess that's unbounded because the parser can't know how much data it will have to buffer, but in practice we're talking like a few dozen bytes most of the time.
  • dmitriid 5y ago
    IIRC there are easily reproducible pathological cases. The author of Sass said it was one of mistakes he made when creating Sass: he didn't require & for nesting everywhere. Unfortunately, on mobile I can't quickly find the relevant links.
    • zeroimpl 5y ago
      I don’t mind the & being required, I just don’t like the fact that there are 2 syntax options depending on whether & is at the start or not. If the parsing problems are that difficult, I’d rather the @nest be always required.
  • eurasiantiger 5y ago
    You could be parsing invalid syntax (forgot a } somewhere), and now your parser tries to nest EVERYTHING until it finds that matching curly brace or errors out at EOF.
  • eyelidlessness 5y ago
    The lookahead isn’t to the next bit of CSS syntax, it’s looking ahead to the next potential selector match in the DOM. If that can’t be resolved, you can’t unblock the CSS resolution to un-suspend the next blocked portion of the initial render
• eyelidlessness 5y ago
  It’s the same reason backtracking is a performance hit in any scenario. CSS is blocking, and if a selector needs to wait for every network resolution and JS parse/execution to resolve it’s essentially as expensive as your worst case scenario.