- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Mar 2025 15:32:17 +0000
- To: public-css-archive@w3.org
> you mentioned escapes as apparently being something new, but they've always been part of functions - you can write `\6c inear-gradient(90deg, red, blue)`. The ident part of a function token just uses normal ident-parsing rules. I am not sure I understand what you were trying to convey to me here. But from re-reading my own comment, I should have expanded on my point a little. When parsing a function against `<dashed-function>`, an implementation simply needs to look for a function whose name starts with `--`. It is already guaranteed to be a valid `<ident>`. It matches `<dashed-ident>`. Assuming more function names were defined to match some production, implementations may choose to internally represent it with the result from parsing the name against this production. This would allow them to later apply serialization rules specific to this production, like re-escaping code points for `<dashed-ident>` and `<custom-ident>`. `--cus\\ tom()` is tokenized then consumed as a function whose name is the string `--cus tom`, so implementation must either serialize it as an identifier, or they should escape it in their internal representation. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10558#issuecomment-2714780812 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 March 2025 15:32:17 UTC