[i18n-activity] custom property names to permissive? (#1487)

aphillips has just created a new issue for https://github.com/w3c/i18n-activity:

== custom property names to permissive? ==
## Proposed comment

https://www.w3.org/TR/css-variables-1/#defining-variables

> A custom property is any property whose name starts with two dashes (U+002D HYPHEN-MINUS), like [--foo](). The <custom-property-name> production corresponds to this: it’s defined as any [<dashed-ident>](https://www.w3.org/TR/css-values-4/#typedef-dashed-ident) (a valid [identifier](https://www.w3.org/TR/css-syntax-3/#identifier) that starts with two dashes), except -- itself, which is reserved for future use by CSS. [Custom properties](https://www.w3.org/TR/css-variables-1/#custom-property) are solely for use by authors and users; CSS will never give them a meaning beyond what is presented here.

The above text defines the custom property name as "any valid identifier". Tracing that definition back to [CSS Values](https://www.w3.org/TR/css-values-4/#typedef-dashed-ident) and thence to [`ident token`](https://www.w3.org/TR/css-syntax-3/#typedef-ident-token), we find that the name can contain ***any*** Unicode code point > U+0080. This includes various special forms of whitespace as well as potential problem characters, such as bidi controls (such as might cause "Trojan Source" attacks). Namespacing is definitely a complicated problem: the I18N WG generally doesn't want groups to cherry-pick characters (thereby excluding certain languages from using the feature).

Most programming languages attempt to address this by adopting some form of restriction for variable names such as those found in [UAX31](https://unicode.org/reports/tr31/) _Unicode Identifier and Pattern Syntax_. In JavaScript, for example, the definition looks like the one found [here](http://es5.github.io/x7.html#x7.6). CSS should probably make similar restrictions on property _names_ (values can remain unrestricted).


## Instructions: 

This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html

1. Create the review comment you want to propose by replacing the prompts above these instructions, but **LEAVE ALL THE INSTRUCTIONS INTACT** 

2. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help.

3. Ask the i18n WG to review your comment.

4. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-\*lreq label(s).

5. Delete the text below that says 'url_for_the_issue_raised', then add in its place the URL for the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use \[...](...) notation – you need to delete the placeholder, then paste the URL.

6. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue. 

7. If you added an \*lreq label, add the label 'spec-type-issue', add the corresponding language label, and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:.

8. Edit this issue to **REMOVE ALL THE INSTRUCTIONS & THE PROPOSED COMMENT**, ie. the line below that is '---' and all the text before it to the very start of the issue.

---


**This is a tracker issue.** Only discuss things here if they are i18n WG internal meta-discussions about the issue. **Contribute to the actual discussion at the following link:**


§ url_for_the_issue_raised


Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1487 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 1 March 2022 17:57:24 UTC