[css-color] Be more explicit that color names are *ASCII* case-insensitive

[fred-wang]

From the CSS color spec:

• "As usual for CSS-defined idents, all of these keywords are case-insensitive." ( https://drafts.csswg.org/css-color/#named-colors )
• "Note: As with all other keywords, these names are case-insensitive. They are shown here with mixed capitalization for legibility." ( https://drafts.csswg.org/css-color/#css-system-colors )
• " Only later did CSS pick it up, at which point the capitalization stopped mattering, as CSS keywords are case-insensitive." ( https://drafts.csswg.org/css-color/#currentcolor-color )

However, the CSS value spec says pre-defined keywords are ASCII case-insensitive:
https://drafts.csswg.org/css-values-4/#keywords

Concretely, ftp://ftp.unicode.org/Public/UNIDATA/CaseFolding.txt has this line:

017F; C; 0073; # LATIN SMALL LETTER LONG S

which means that ſilver is case-insensitively equal to silver. However, it is not ASCII case-insensitively equal to silver (only a-z <-> A-Z equivalence are considered in that case).

Blink, Webkit and Gecko seems to treat colors as ASCII case-insensitive.

Note: I'm opening this for the color spec, but it is probably worth checking that for other CSS specs too.

[tabatkins]

Agreed, I'll fix to link to the definition of ASCII case-insensitive.

And yes, any other instances of "case insensitive" that don't link to the Infra definition are a bug and should be fixed, please feel free to point them out.

[svgeesus]

For the CSS named colors from X11, those are all ASCII-only in any case so the distinction (while useful to clarify) has no observable effect unless more are added later which use full Unicode.

The color() function can refer to an ICC named color profile. But I just checked ICC 4.3 specification, section 10.15 namedColor2Type; the prefix, suffix, and color root name are all clearly stated to be 7-bit ASCII.

[fred-wang]

@svgeesus Having ASCII-only names is not enough because ftp://ftp.unicode.org/Public/UNIDATA/CaseFolding.txt has mappings from non-ASCII to ASCII characters. As I pointed out in the description, U+017F LATIN SMALL LETTER LONG S is mapped to LATIN SMALL LETTER S U+0073 when doing Unicode case-insensitive comparison. Which means that "ſilver" would be treated as "silver" if CSS doesn't restrict to ASCII case insensitive.

FYI I recently fixed a similar bug in Chromium where e.g. <link rel="ſtylesheet"> was accepted contrary to what the HTML5 spec says and what Gecko & WebKit implement. You can still check that inconsistency with release builds.

[fred-wang]

And yes, any other instances of "case insensitive" that don't link to the Infra definition are a bug and should be fixed, please feel free to point them out.

In two notes of the css-values spec previously mentioned, "case-insensitive" is used where ASCII case insensitive is meant (https://www.w3.org/TR/css-values-4/#frequency and https://www.w3.org/TR/css-values-4/#absolute-lengths). Difference could be observable with "KHz" (using U+212A Kelvin Sign).

[Crissov]

Other notable cases are

• İ→i↔I, ı→I↔i or with Turkish rules: İ↔i, ı↔I
• ẞ→ß→SS↔ss even with German rules

00DF; F; 0073 0073; # LATIN SMALL LETTER SHARP S
017F; C; 0073; # LATIN SMALL LETTER LONG S
1E9E; F; 0073 0073; # LATIN CAPITAL LETTER SHARP S
1E9E; S; 00DF; # LATIN CAPITAL LETTER SHARP S

0130; F; 0069 0307; # LATIN CAPITAL LETTER I WITH DOT ABOVE
0049; C; 0069; # LATIN CAPITAL LETTER I
0049; T; 0131; # LATIN CAPITAL LETTER I
0130; T; 0069; # LATIN CAPITAL LETTER I WITH DOT ABOVE

FB00; F; 0066 0066; # LATIN SMALL LIGATURE FF
FB01; F; 0066 0069; # LATIN SMALL LIGATURE FI
FB02; F; 0066 006C; # LATIN SMALL LIGATURE FL
FB03; F; 0066 0066 0069; # LATIN SMALL LIGATURE FFI
FB04; F; 0066 0066 006C; # LATIN SMALL LIGATURE FFL
FB05; F; 0073 0074; # LATIN SMALL LIGATURE LONG S T
FB06; F; 0073 0074; # LATIN SMALL LIGATURE ST

01F0; F; 006A 030C; # LATIN SMALL LETTER J WITH CARON
1E96; F; 0068 0331; # LATIN SMALL LETTER H WITH LINE BELOW
1E97; F; 0074 0308; # LATIN SMALL LETTER T WITH DIAERESIS
1E98; F; 0077 030A; # LATIN SMALL LETTER W WITH RING ABOVE
1E99; F; 0079 030A; # LATIN SMALL LETTER Y WITH RING ABOVE
1E9A; F; 0061 02BE; # LATIN SMALL LETTER A WITH RIGHT HALF RING

00B5; C; 03BC; # MICRO SIGN
212A; C; 006B; # KELVIN SIGN
212B; C; 00E5; # ANGSTROM SIGN

[faceless2]

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.

This would match "SILVER", "Silver", "ſilver" and "silver".

[fred-wang]

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.

[tabatkins]

Yeah, CSS (and most of the web) is very intentionally either (a) ASCII case-insensitive (mapping only a-z and A-Z together) or (b) fully case sensitive (two strings are equal iff they're codepoint-equal). Nothing between those two should ever be introduced without a very good reason.

Fonts, I believe, have legacy constraints causing them to use the in-between algo of "default caseless", but I'm going to file a bug to make sure that's actually necessary.

[svgeesus]

Fixed by 51b9c15