- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Mar 2022 16:57:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Custom property names too permissive`, and agreed to the following: * `RESOLVED: Use HTML restrictions for custom idents` * `RESOLVED: illegal characters in an ident can be escaped` * `RESOLVED: Invalid ident characters are treated as DELIM tokens` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Custom property names too permissive<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7129<br> <fantasai> TabAtkins: i18nWG raised issue about custom idents, which allow any Unicode codepoint above a certain codepoint<br> <fantasai> TabAtkins: There are some concerns about e.g. bidi characters corrupting the display of the code<br> <fantasai> TabAtkins: Also argument for consistency in what characters allowed across languages<br> <fantasai> TabAtkins: JS follows UAX?? rules for characters allowed in idents<br> <fantasai> TabAtkins: HTML allows a different but largely compatible range of characters<br> <fantasai> TabAtkins: In one of my Tweets, I showed off using weird Unicode rules<br> <fantasai> TabAtkins: e.g. different emoji are valid or invalid<br> <fantasai> TabAtkins: I agree with i18n feedback, reasonable to partially restrict these<br> <fantasai> TabAtkins: e.g. no reason to allow bidi override chars in CSS idents<br> <fantasai> TabAtkins: so I suggest adopting either HTML rules or JS rules<br> <Rossen_> q?<br> <fantasai> TabAtkins: don't have a strong opinion on which to go for<br> <fantasai> TabAtkins: Otherwise I'd go with HTML rules by default<br> <emilio> Scribenick: emilio<br> <emilio> fantasai: I think this is fairly reasonable, but I don't know the differences between the rules so I don't have an opinion on those yet<br> <fantasai> TabAtkins: JS rules are a bit more strict, they disallow chars that look like punctuation<br> <fantasai> TabAtkins: HTML gives exact codepoint ranges<br> <fantasai> TabAtkins: Reason I'd go with HTML is to guarantee being able to write selectors for custom elements, without ever having to escape<br> <Rossen_> ack fantasai<br> <fantasai> fantasai: That sounds reasonable, let's go with that<br> <fantasai> Rossen_: Makes sense, any downsides to it?<br> <fantasai> TabAtkins: Any change to make more restrictive, could potentially make some stylesheets invalid<br> <fantasai> TabAtkins: potentially breaking code that works<br> <fantasai> Rossen_: And with HTML rules we'd have fewer breakage<br> <fantasai> Rossen_: seems like path of least destruction<br> <fantasai> Rossen_: Anyone would like to argue against the change entirely?<br> <fantasai> Rossen_: If not any objections?<br> <fantasai> Rossen_: Taking the silence as a no<br> <fantasai> RESOLVED: Use HTML restrictions for custom idents<br> <fantasai> TabAtkins: Got 2 sub-issues<br> <fantasai> TabAtkins: One is whether to allow illegal characters to be escaped in an identifier<br> <fantasai> TabAtkins: JS doesn't allow that, you can escape for readability but not to avoid the identifier restrictions<br> <fantasai> TabAtkins: but CSS has traditionally always allowed escapes for everything, so don't see a strong reason to disallow<br> <faceless> +1 from us too<br> <fantasai> TabAtkins: So I would prefer to go with illegal chars can be escaped<br> <fantasai> fantasai: I strongly agree with that<br> <fantasai> Rossen_: Any objections for allowing illegal characters to be escaped in an ident?<br> <fantasai> RESOLVED: illegal characters in an ident can be escaped<br> <fantasai> TabAtkins: Next question is how do we handle the illegal characters<br> <dbaron> That doesn't allow nulls in idents, does it?<br> <fantasai> TabAtkins: Do we censor them into e.g. U+FFFD<br> <fantasai> TabAtkins: or drop them entirely?<br> <fantasai> TabAtkins: I'd prefer to drop them, because it would more clearly result in invalid code<br> <fantasai> TabAtkins: so if we allow to work but censored it wouldn't prevent use in source text, which was the goal of i18n<br> <fantasai> TabAtkins: so would prefer to exclude from the ident production<br> <fantasai> <fantasai> +1<br> <tantek> +1 TabAtkins<br> <fantasai> Rossen_: [missed]<br> <fantasai> TabAtkins: No, would not be changing existing rules for censoring rules. Currently lone surrogates etc. do that<br> <fantasai> TabAtkins: Those are in there for UTF-8 well-formedness and C compatibility<br> <fantasai> TabAtkins: They have a reason to be censored out at technical low level<br> <fantasai> TabAtkins: these restrictions are for human reasons, so would restrict differently<br> <Rossen_> ack fantasai<br> <fantasai> fantasai: So should we resolve that they would make the production invalid? (That's what was proposed right?)<br> <TabAtkins> --（╯°□°）╯<br> <fantasai> TabAtkins: yes<br> <fantasai> TabAtkins: if you put this ^ as a custom property name, the degree sign is not a valid character<br> <fantasai> TabAtkins: so it would make an ident, a delim, a parenthesis, and a ???<br> <fantasai> TabAtkins: That's definitely not an ident, because it's multiple tokens not an ident token<br> <bmathwig> Is there a practical use case for doing something like that? Seems more like a developer having fun rather than good quality code.<br> <fantasai> TabAtkins: Proposed resolution is that it would break into multiple tokens<br> <fantasai> fantasai: What kind of token are these invalid characters going to be?<br> <fantasai> TabAtkins: DELIMs, one codepoint at a time<br> <fantasai> TabAtkins: Characters without a specific role are generally handled as DELIM<br> <fantasai> TabAtkins: and we only use certain DELIMs in certain places<br> <TabAtkins> the degree sign isn't a valid ident char under the HTML rules, so this would produce an ident, a delim containing the degree sign, an ident, a delim, and finally an ident<br> <fantasai> RESOLVED: Invalid ident characters are treated as DELIM tokens<br> <faceless> present-<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7129#issuecomment-1069331981 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 March 2022 16:57:46 UTC