- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 May 2023 23:00:17 +0000
- To: public-css-archive@w3.org
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-syntax] Give up on <urange> production? == In the previous versions of Syntax I tried my best to be grammar-agnostic, so you could parse CSS generically, and only throw out invalid rules/declarations as a final step. Implementations actually grammar-checked as they went and didn't add invalid stuff to the stylesheets, but that was meant to be an unobservable performance optimization. However, we also wanted to fix the "`u+a { color: red; }` is invalid because `<urange>` isn't valid in a selector" problem; CSS2 defined `<urange>` as a generic token. We discussed this in the mailing list (transferred to #3588), and I ended up solving it by defining a very complex production that required preserving the representation of tokens, which nothing else in the whole spec required. Accordingly, no browser has actually implemented this: Chrome just never fixed the bug, and Firefox implemented it by [invoking a different tokenizer](https://github.com/servo/rust-cssparser/blob/master/src/unicode_range.rs#L102). (`<an+b>` is *also* now a complex production, but aside from preserving whether a positive number had a `+` or not, it relied on the standard token values, so wasn't as problematic. Everybody seems to have actually followed the spec text.) However, now that Syntax is required to grammar-check as it parses, we can potentially correct this in a less weird way, by having a tokenizer flag that gets invoked *only* for the 'unicode-range' descriptor and allows the tokenizer to produce urange tokens again. This'll better match what Firefox is doing, and should make it easy for Chrome to correctly implement as well. Thoughts? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8835 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 12 May 2023 23:00:19 UTC