[css-color-4] The color() function <ident> doesn't seem to be future proof

[karip]

The color() function's <ident> can be either a predefined colorspace or a custom identifier. Custom identifiers can't be predefined colorspaces ('srgb', 'rec-2020', etc.): "predefined colorspace keywords .. are excluded from this <custom-ident>".

It seems that it won't be possible to add new predefined colorspaces because they could potentially break user defined custom identifiers:

Let's say I create a web page which uses my colorspace with a custom identifier 'rec-2100'. Then, the CSS working group decides to create a new predefined colorspace called 'rec-2100'. Since predefined colorspaces can't be used as custom identifiers, the new predefined colorspace will override my colorspace and breaks my web page.

Would it be better to differentiate custom identifiers with quotes or something so that they won't clash with predefined colorspaces?

Or are you certain that there will never be new predefined colorspaces? I think there is a plan to add at least one predefined CMYK colorspace.

[svgeesus]

This is a very good point. I agree with your concern.

There were similar issues with the font property, which were solved by requiring any clashes to be quoted (you can reference a font that is actually called "serif", but serif without quotes is the generic font family. And that helped when we extended the generic font families in Fonts 4.

In this case, maybe it makes sense for the predefined ones to be unquoted and for the user-supplied ones to always be quoted? @tabatkins what do you think?

[tabatkins]

Yeah, letting user-supplied names play in the exact same namespace as predefined ones has bitten us many times in the past. Either forcing user-defined to be strings or requiring them to be --idents would work; I don't have a strong preference for which.

Usually we use strings when the names come from outside the control of the author, and let author-supplied names remain idents, so I guess I lean slightly toward --idents, since the names are declared by the author in the @color-profile rule.

[svgeesus]

I have a slight preference for forcing the user-defined ones to be strings, because I expect them to be less common, and it means the predefined ones like display-p3 don't have to become "display-p3".

It is also more in keeping with fonts, where the predefined (generic) ones are unquoted and the author-supplied ones should be quoted (a design error, must would have been better)

[bkardell]

I lean toward -- because being consistent about how custom things are expressed is very easy to remember and teachable.

[Crissov]

Uch, please no more ugly double hyphens – or at least not as prefixes (i. e. foo--bar is better than --bar) – when <string> within quotation marks is available and well established elsewhere, e.g. in user-defined font names (in font-family, from @font-face).

[tabatkins]

it means the predefined ones like display-p3 don't have to become "display-p3".

They wouldn't, that's the point. The predefined ones stay exactly as they are, it's the user-defined that have to do something else.

no more double hyphens

They're well-established and will show up more regardless. Names in strings are the rare thing; as I said, we use them pretty much exclusively for names that come from outside CSS, and thus have no guarantees of being friendly to CSS tokenization rules (like font-face names, variation axis names, lang codes, etc.) We have no precedent for using them for things defined by the CSS author. (@font-face just works with the existing weird pattern that font-family established since CSS1; if we were doing it today it would probably instead be that all "local" fonts required strings, and all @font-face required --idents.)

[svgeesus]

@tabatkins is there a procuction for --ident? I can find Author-defined Identifiers: the <custom-ident> type but that is not the same.

Or is it the <custom-property-name> which seems to have the same link as custom properties ?

[tabatkins]

Ah yeah, I don't have a good general-purpose production for it. I can add one in custom properties, I guess.

(And I don't know what you mean, <custom-property-name>'s link is https://drafts.csswg.org/css-variables-1/#typedef-custom-property-name.)

[tabatkins]

Done, you can refer to <<dashed-ident>> now: e5b1c00

[svgeesus]

@karip thanks for reporting this. Predefined spaces now use <ident> while custom spaces use <dashed-ident>, so are future proof against later additions to the predefined spaces.

[karip]

Should some specification mention that custom properties (CSS variables) and custom color profiles live in different namespaces? It's possible to use the same identifier as a CSS variable and custom color profile and they don't override each other, or do they? Example:

:root {
  --myident: blue;
  --myident: green; /* overrides blue */
}
/* custom color profiles - they won't override --myident custom property */
@color-profile --myident { src: url('http://example.org/swop-coated.icc'); }
@color-profile --myident { src: url('http://example.org/indigo-seven.icc'); } /* overrides swop */

/* --myident as a CSS variable and --myident as a color profile. is this valid? */
<body style="color: var(--myident); background-color: color(--myident 0.1 0.2 0.3 0.4);">HELLO WORLD</body>

[tabatkins]

They have no relation to each other, yes. No need to call it out specially; they're just different concepts. It's the same as creating an @keyframes width {...}.