Postpone all bells and whistles to Level 2

[LeaVerou]

Right now we have these for v1:

• Lossless color space conversion (e.g. LCH → P3)
• Gamut mapping
• Manipulating coordinates in current color space
• Manipulating coordinates in a different space (basically sugar over converting to a different space, manipulating coordinates, then converting back)
• Difference between two colors (ΔE)
• String parsing (e.g. what color is rebeccapurple?)
• WCAG 2.1 (or it's successor) color contrast (for any color space, not just sRGB)
• Prototyping new functionality for incubation, before standardization

I think Level 1 should focus around having an object to represent colors that other APIs can use, since that is the most pressing need. Everything else that is nonessential for this use case can move to Level 2.

Meaning this can move to Level 2:

• Difference between two colors (ΔE)
• Gamut mapping
• WCAG 2.1 (or it's successor) color contrast (for any color space, not just sRGB)
• Lossless color space conversion (e.g. LCH → P3)
• Manipulating coordinates in a different space (basically sugar over converting to a different space, manipulating coordinates, then converting back)

This still seems essential and I’m hoping it can stay:

• Manipulating coordinates in current color space
• String parsing (e.g. what color is rebeccapurple?)

but worst case, we could ship Color with just a (colorspace, coords, alpha) constructor signature and immutable coordinates.

ColorSpace objects will have to be part of Level 1, but we can defer making them contructible.

Thoughts, @svgeesus?

[tabatkins]

Before deciding on what to punt, can you elaborate on why you're thinking we need to punt things? Usually we punt because either (a) some features aren't fully-baked and we don't want to delay the rest of the spec on them, or (b) a fully-baked feature is more complex than implementors want to deal with for now (or maybe it's simple enough by itself, but contributes to the spec as a whole being more complex than they want for now), so by punting they'll hopefully be amenable to taking on that complexity later.

Is either of these the case for any of these features?

[svgeesus]

Lossless color space conversion (e.g. LCH → P3)

Without that, the API basically offers no value and every color has to be manipulated in the colorspace it was declared in. Which, together with

Difference between two colors (ΔE)

means that - guess what - people will do geometric distance in display-p3 with all the attendant problems.

Both of these are well established, and computationally simple (at least, DeltaEOK is super simple and arguably the best) so removing them seems super odd to me.

[LeaVerou]

Before deciding on what to punt, can you elaborate on why you're thinking we need to punt things? Usually we punt because either (a) some features aren't fully-baked and we don't want to delay the rest of the spec on them, or (b) a fully-baked feature is more complex than implementors want to deal with for now (or maybe it's simple enough by itself, but contributes to the spec as a whole being more complex than they want for now), so by punting they'll hopefully be amenable to taking on that complexity later.

Is either of these the case for any of these features?

Both really. Right now this effort is trying to solve two pain points at once: (a) Provide an object that can represent colors that APIs can use for input and output, and (b) provide authors with color handling conveniences.

(a) is a much easier problem than (b), both in terms of API design, as well as implementation, and is a far bigger pain point. It gives APIs a structured object to return that can later be upgraded with conveniences, while right now their only option is to return serialized colors. It means APIs can ship with Color support while we work to improve the API to make it more useful. There is no need for the former to be blocked on the latter.

(also gee, thanks for explaining why we defer things, I had no idea! 😅)

[svgeesus]

Note too that CSS Typed OM 1 used to have a bunch of color conversion stuff, which was all removed in favor of placing it in this Color API. So punting that to a later version seems super odd.

[LeaVerou]

As discussed in a breakout between @svgeesus and I yesterday, I think it's ok to keep color conversion, as long as we defer ColorSpace objects and ship v1 with a few magic color spaces specified via strings. Thoughts, @tabatkins ?

[tabatkins]

Yup, that seems fine to me. Having the same degree of color conversion as CSS offers via RCS/etc seems appropriate for level 1, but more custom stuff can wait. 👍

[tabatkins]

(also gee, thanks for explaining why we defer things, I had no idea! 😅)

Establishing rhetorical bounds is useful even when we assume that everyone is aware of the space. Here, I was specifically trying to get answers to two questions, and framing them a little seemed reasonable. I'm certain you've done the same plenty of times in our discussions. ^_^

[LeaVerou]

So to make this proposal more concrete, I just pushed a TS file outlining what API shape I propose for v1: https://github.com/WICG/color-api/blob/main/color-api-v1.d.ts

Let me know what you think!

[svgeesus]

That v1 shape looks good to me.

The comments about items pushed to v2 are also helpful, thanks for those.

[svgeesus]

I'm certain you've done the same plenty of times in our discussions.

I do recall explaining negative numbers, yes :/

[svgeesus]

@LeaVerou as there have been no negative comments on the v1 API shape how do we move that forward to get it into the V1 spec?

An updated doc would also help get more eyes on it.