- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Mar 2022 19:29:08 +0000
- To: public-css-archive@w3.org
Agenda+ to discuss restricting the allowed codepoints in an [ident sequence](https://drafts.csswg.org/css-syntax/#consume-name) (used in keywords, function names, dimension units, selectors, property names, etc). Possible options: * use the [UAX31 categories](https://unicode.org/reports/tr31/#Figure_Code_Point_Categories_for_Identifier_Parsing), matching JS identifiers * use the post-ASCII part of HTML's [custom element name restrictions](https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name), to ensure that selectors can match all custom element names without needing escaping Then there are subsequent questions. First, what should we do about characters so restricted that *are* used in an identifier sequence? * Treat them like we do lone surrogates, and replace with U+FFFD * Disallow them from the production at all, so an identifier valid today with a restricted character in the middle would instead become two identifiers with a DELIM token containing the restricted character. (I'm inclined toward this, as it would cause most usage of the restricted character to become invalid at parse-time, such as in custom property names, and thus would discourage its usage.) Second, should we allow escapes to represent the restricted character in identifiers? * JS, [as far as I can tell](http://es5.github.io/x7.html#x7.6), doesn't allow it. Their restriction is rather broad, tho - it's intended to make it so that *no* identifier that would be illegal to write literally can be written with escapes (in other words, they disallow an ident that could only be written by using escapes) - this disallows things like escaping a dash or period, which CSS has historically allowed and probably can't restrict * Just let it work. I'm inclined to go this way. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7129#issuecomment-1064415863 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 March 2022 19:29:10 UTC