Re: [css-houdini-drafts] [css-typed-om] CSSColorValue section needs WG review (#1039)

> An ICC profile is sufficient, but not always necessary. [snip]

Ah, makes sense. Bringing this back to the topic, tho, wouldn't CSS want access to this as well, implying we want a Houdini API to allow JS-backed color profiles? Then Typed OM would have access to such things.

(Typed OM colors could always be converted by hand with JS code, it just wouldn't hook into the `.to()` function unless we added Houdini color profiles to CSS.)

> CSS can do late gamut mapping only when a color is displayed and only ever needs to map to the gamut of the display device. When you can read coordinates, there needs to be more control about when or if to gamut map.

I'm not sure I understand - you *can* read individual coordinates in CSS; that's what the color functions are. I suspect I'm missing something here - could you elaborate on what you mean?

> I strongly suspect it would not. Presenting them as radians is inconsistent with both CSS colors (where unitless hues are in degrees) and everywhere else in the literature where a hue is specified. Nobody needs hues in radians. Remember, authors are above theoretical purity, also there are many types of consistency at play, which are often at odds with each other (in fact, we are about to add a new TAG design principle on this).

Right, but the fact that all angle-wrangling functions in JS use radians (and thus would require an annoying pair of conversions to use with a degree-based API) is something I think is pretty important.

(I definitely prefer using degrees myself, and in angle-heavy pages I've written, I defined my own sin/cos/etc functions that take degrees instead, just wrapping the built-ins with a bit of conversion code.)

In any case, not super relevant here, I'll drop this tangent. Typed OM gives you access to both, and CSS favors degrees anyway. ^_^

> The thing is, because this possibility exists, other APIs (either native to the platform, or author-created ones) cannot declare that they do not accept such colors. [...]

Sure, platform APIs need to deal with that possibility, most likely by failing early when they can't resolve them down. But most (all?) platform APIs that want to work with color are going to want to take CSS strings as an option anyway, *because* they're ubiquitous and easy to obtain from other APIs, and so they'll need to deal with the exact same issues there.

However, your example seemed to be about the difficulty of userland code doing color manipulation having to deal with this complexity, and I think I demonstrated that's not actually an issue. Most of the time they won't see such complexity anyway, and the rare times they do, it's because someone grabbed a value that *cannot be expressed* in a JSColor in the first place; any place they *could have* obtained a JSColor, they'll get a similarly-simple Typed OM value.

> That is only one potential design, and IMO not the best one for a Color API (it works fine for Typed OM however).

Interesting - what is a better API, in your opinion? What I described looks to be like what you're doing in Color.js, right?

(Possibly this is better discussed in a separate issue, since it might be an involved conversation.)

> So is there actually any required branching with this sort of API?

If I read your previous comment correctly, you stated that, since a Typed OM color could be in any of the color spaces, and thus can have various types of channels and different accessor properties to those channels, authors would need to handle each of the color spaces individually whenever they write any color-manipulating code. (Similar to today's world where people have to handle several possible color functions that can be returned by CSS strings.) Is this right?

If that's an accurate read, then I don't think the conclusion is correct - if you're doing color manipulation, you can call `.to()` on the values to put them in a single chosen space and do all your work there. Does this make sense?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1039#issuecomment-845269356 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 20 May 2021 16:28:26 UTC