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

Postpone all bells and whistles to Level 2 #37

Open LeaVerou opened 5 months ago

LeaVerou commented 5 months ago

Right now we have these for v1:

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:

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

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

(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 commented 3 months ago

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 commented 3 months ago

That v1 shape looks good to me.

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

svgeesus commented 3 months ago

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

I do recall explaining negative numbers, yes :/

svgeesus commented 1 week ago

@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.