- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 May 2023 08:11:25 +0000
- To: public-css-archive@w3.org
> Maybe we can do this, but still hardcode a check into the parser that works on the string value of the entire declaration? Yeah, that was my thinking. We say in prose that (original) strings that don't match the microsyntax are invalid (parse-time). This is arguably "ugly", but at least it's isolated to `unicode-range` and the rest of CSS doesn't have to care. > Maybe a string, but we could also have really easy used existing syntax. If we need unicode ranges in a new property/descriptor in the future, would we use a `<string>` for that? Asking because we should probably keep the look-at-the-original-string-hacks to a bare minimum. > having a tokenizer flag that gets invoked only for the 'unicode-range' descriptor and allows the tokenizer to produce urange tokens again. By the way, I think we can still implement "parse the original string" (in Blink) even if it's specified like this, as it's not observable what we actually do (I think). I'm just a _little_ worried that we're opening the door to lots "oh, we'll just switch tokenizer mode to solve that" in the future, which may result in a lot of new "Chrome never fixed the bug"-situations. On the other hand we seem to be opening _some_ unwanted door regardless, so if the mode-switch is a substantially nicer spec than the alternatives, then maybe it indeed is the least bad option ... -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8835#issuecomment-1554208141 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 19 May 2023 08:11:27 UTC