- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 18 May 2023 18:23:46 +0000
- To: public-css-archive@w3.org
> Thought: implementations must already be able to retain the original string for declarations due to custom properties, can we work with that here? Yeah, that probably works, tho it would mean that we lose the ability to check the syntax for the property at parse time. Maybe we can do this, but still hardcode a check into the parser that works on the string value of the entire declaration? > How would we define unicode-range if we introduced it today? unicode-range: <string>? Maybe a string, but we could also have really easy used existing syntax. For example, if we'd just used `u-` rather than `u+` this wouldn't be a problem at all: `u-14a` and `u-100-14a` are single idents with unambiguously interpretable values, and `u-1??` is an ident followed by `?` delim tokens. The grammar would just have been `<urange> = <custom-ident> '?'*`, with a restriction that no whitespace is allowed in the production, and then some prose rules about how to interpret the ident's value + question marks into a range. Or we could've done the same with a hash token, since that's already used for hex values in colors; it also uses ident syntax after the hash, so it would parse identically - `#100-14a`, etc. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8835#issuecomment-1553447915 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 18 May 2023 18:23:47 UTC