4 ms·
The problem is not to tell selector from definition (of course it can, otherwise grammar would be non-reducible). The problem is how far in an array of tokens t
by wruza 4y ago
The problem is not to tell selector from definition (of course it can, otherwise grammar would be non-reducible). The problem is how far in an array of tokens the distinction can be seen.
Parsers know the current state and where to go next out of previous reductions and a few lookaheads which they can use at places known to be clear of ambiguity in a ~fixed number of lookaheads. Parsing something that diverges only down few pages of tokens is problematic size/speed/algo-wise, but the question is how much does that cost really and who should pay.
Edit: But honestly I think this is all wrong direction. Any technology, format, method has 1. features and 2. form. Form is irrelevant because you can make tools to convert any form into any. Features are important because you can’t add features by tooling. But $subj adds zero features, only a new form which is already feels like a compromise. Why do that then? We have to brush our tools instead, e.g. create default nginx-scss plugin, standalone scss caching servers etc. Then everyone could use extended syntax without resorting to all-in-one monstrosities like webpack.
- scotty79 4y agoNext { or ; is not few pages down. This all seems like purely academic objection that in practice could be made equally fast.
- wruza 4y agoYep, that’s why I find it questionable too. Next { or ; is not few pages down A little nuance is that when it is, we either want to make that illegal or to process this case anyway. Both ways open a next can of worms.
- scotty79 4y agoI guess, if you want to write slowest CSS file on the planet by cramming together three pages of selectors before you open a bracket ... be my guest.
- danielvaughn 4y agoYeah this is my intuition as well, though I haven't spent much time thinking about the problem. Like, yeah, if you write very non-performant code, it won't perform well. So what? Don't write stupid code.
- jakelazaroff 4y agoThe issue is that the person who ends up suffering isn't the developer that writes the CSS. It's the person who has to use the website. If I'm trying to find a local emergency room, I really don't want to have to waste time because a developer wrote (or some tool generated!) slow CSS.
- treeman79 4y agoI had hired in at a new company and was getting annoyed with how slow everything was so I started digging into the Javascript and CSS. I started seeing a lot of references to Chuck Norris. After further digging, found that the entire test library suite was being added to code. Site load time was halved after fixing.
- wruza 4y agoTo understand why this is a problem even with “good” css, one has to understand how parsers work. It doesn’t matter that all css will be good in practice. The entire theoretical possibility of a problematic case (i.e. unbounded number of lookaheads) changes a class of parser required to parse it. Not all grammars are equal and they may require different methods. One grammar may be LALR(const) compatible, and the other may be parsed only with GLR. There is no easy way to use a dumb and quick parsing method once you commit to a grammar (not to a way of writing sources!) in which ambiguity can survive for an indefinite time, even if it’s always short in practice.
- spankalee 4y agoI personally trust the feedback from the actual maintainers of such performance critical parsers.
- mort96 4y agoConsider this code: color:hover .foo .bar .qux div span You have no idea whether to parse that as a property (setting `color` to that string) or as a nested selector (a span below a div below .qux below .bar below .foo below a color element that's being hovered over). You only know that it's a property if you see a `;` or a `}`, or a nested declaration if you see a `{`. So yeah, the ambiguity might not be resolved for a pretty long time. And, unless there's some aspect to CSS's grammar I'm not thinking of, this ambiguity exists for every single property (even for stuff like `background-color: blue` -- the parser shouldn't know that `background-color` isn't an HTML element or that `blue` isn't a selector). It really wouldn't surprise me if adding unbounded lookahead to every single CSS property would cause a pretty significant parsing slow-down.
- somishere 4y agoI guess I'd just like to see a good example. CSS is fairly process intensive, not to parse, but because it directly effects the render. Surely compiling a sheet with some lookahead magic isn't going to explode anything that you couldn't already explode with a 'will-change'?
- silvestrov 4y ago> Form is irrelevant because you can make tools to convert any form into any No, form is not irrelevant. People don't write bug-free code. The form has to work reasonable well even when there is a syntax error in the code. C++ templates is a main example where this often goes hairwire.