Edit: I put together (painfully typed out on a phone) an example regex[1] to use the color:hover example. It isn't perfect, but it also isnt boundless.
Edit: I put together (painfully typed out on a phone) an example regex[1] to use the color:hover example. It isn't perfect, but it also isnt boundless.
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.
This all seems like purely academic objection that in practice could be made equally fast.
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.
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.
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.
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.
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.