search

WICG / color-api

A proposal and draft spec for a Color object for the Web Platform, loosely influenced by the Color.js work. Heavily WIP, if you landed here randomly, please move along.
https://wicg.github.io/color-api/
Other
130 stars 3 forks source link

Restrictions on the identifier of user-registered color spaces? #23

Open danburzo opened 2 years ago

danburzo commented 2 years ago

The CSS Color Level 4 mentions that the @color-profile at-rule works with <dashed-ident> to allow the registration of additional color spaces. The current spec mentions the ability to register color spaces. Will these color spaces need to be prefixed with --?

I'm in the process of implementing generic color serialization in the culori color library and was wondering whether a color space such as Jzazbz should be serialized to a CSS color value as color(jzazbz j a b) or color(--jzazbz j a b), such that the color space definition can be registered by the library consumer on their web pages.

tabatkins commented 2 years ago

No, Color API spaces don't need a -- prefix.

We don't currently have any way to bridge between @color-profile rules and Color API registered spaces; you can't use @color-profile spaces in Color API, and can't use Color API spaces in color().

We do plan to allow them to be used together, but we're not yet sure how. That said, I'm almost certain it won't be by naively merging the namespaces. Instead, I suspect that either we'll come up with an alternate syntax for referring to a Color API space by name (which would serve the same purpose as the -- requirement in @color-profile, preventing collisions with built-ins); or we'll have some way to plumb a Color API space into @color-profile more directly, like an additional registration function, or perhaps a way to refer to a Color API space in @color-profile/src, either of which would mean they'd obey the -- requirement when you ref them in color().

Sorry that, as far as I can tell, this doesn't help you out with your particular issue. ^_^

danburzo commented 2 years ago

Thanks, @tabatkins, I appreciate the insight!

If I understand correctly, new ColorSpace("hsv") will make it into the <color> CSS type either as color(§hsv h s v / alpha) (with the § to be defined) or color(--hsv h s v / alpha) (with the plumbing between Color API and @color-profile to be defined).

The HSV example in the README also hints at the idea of a custom serialization (e.g. hsv(h s v / alpha)), which would require a parse counterpart to call on values found wherever the <color> CSS type is expected, but this kind of unrestrained color syntax sounds very complex.

LeaVerou commented 1 year ago

If I understand correctly, new ColorSpace("hsv") will make it into the <color> CSS type either as color(§hsv h s v / alpha) (with the § to be defined) or color(--hsv h s v / alpha) (with the plumbing between Color API and @color-profile to be defined).

No, these are programmatic modifications, at least for now. I'll open another issue about integrating the two.

The HSV example in the README also hints at the idea of a custom serialization (e.g. hsv(h s v / alpha)), which would require a parse counterpart to call on values found wherever the <color> CSS type is expected, but this kind of unrestrained color syntax sounds very complex.

Yeah, I'm not sure there are use cases for this, and I'm inclined to punt for L1.