- From: Frédéric Wang via GitHub <sysbot+gh@w3.org>
- Date: Sun, 15 Dec 2019 14:58:22 +0000
- To: public-css-archive@w3.org
> Surely this is the same situation that exists for font family names, in which case the "default caseless" matching referenced there is appropriate in this case as well? https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#font-family-casing. Correct. The difference is that for the css-color and css-values specs, these are pre-defined ASCII strings for which the matching "LATIN CAPITAL LETTER SHARP S" or "KELVIN SIGN" with "S" and "K" does not seem intentional. But the font-family names are user-specified, it seems reasonable to apply case equivalences for non-ASCII (e.g. accented characters), and the case folding method is clearly explained in the paragraph you mentioned. Going over other CSS specs quickly, the other instances I found are: * "All Selectors syntax is case-insensitive within the ASCII range (i.e. [a-z] and [A-Z] are equivalent), except for parts that are not under the control of Selectors." https://www.w3.org/TR/selectors-3/#casesens => For non-exception this is just ASCII-case insensitiveness * "The matching of C against the element's language value is performed case-insensitively within the ASCII range. " https://www.w3.org/TR/selectors-3/#lang-pseudo => Same here. * " Pseudo-class names are case-insensitive. " https://www.w3.org/TR/selectors-3/#pseudo-classes => I wonder if this can be restricted to ASCII case-insensitive? * "CSS style sheets are generally case-insensitive, and this is also the case for media queries. " https://www.w3.org/TR/css3-mediaqueries/#syntax => Same here. -- GitHub Notification of comment by fred-wang Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4599#issuecomment-565816911 using your GitHub account
Received on Sunday, 15 December 2019 14:58:24 UTC