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

> First, the extensibility needed for a Color object is broader than the kind of extensibility afforded by CSS itself (e.g. in JS adding new color spaces can be done by providing conversion code -- CSS's @color-profile cannot provide that).

Could you open an issue for this? I was under the impression that an ICC profile was sufficient for color space conversions; if we will indeed want more than that, we should explore the details. CSS probably wants access to this, then, so they could use such a space in `color()`, which would be an argument for a new Houdini API.

> Most algorithms in the spec are also currently very underspecified. 

If we assume (as I did when writing the spec) that the relevant CSS specs defining the types are "in scope" for understanding/implementing the related Typed OM types, then it's exactly as specified as Color 4 is (and, unless it's related to Typed OM-specific details, *should* have its specification live in Color 4, imo). Your questions about details of conversion and gamuts are, afaict, exactly as relevant for Color 4, aren't they? I don't *think* there's any convenient censoring of details that CSS can rely on that Typed OM accidentally exposes here.

(But I *am* going to add some more explicit links back to Color 4 here, based on y'all's feedback.)

> ```
> let lchColor = color.to("lch");
> color.l.value = color.l.value * 1.2;
> ```

This could be written in slightly shorter ways, fwiw. `color.l = color.l.value * 1.2;`, or `color.l.value *= 1.2;`.

But yeah, this is the major API hurdle that a JSColor wouldn't have to deal with.

> If this was about hue, because these objects need to reflect the actual CSS syntax it means authors that want to handle hues need to first convert whatever CSSUnitValue object they get into a number of degrees (since most algorithms expect that).

I strongly suspect JSColor would present their raw-`double` angles as radians; all JS and web-platform APIs consistently do.

(The [canonical unit](https://drafts.csswg.org/css-values/#angles) for CSS angles *is* deg, tho, so computed-values or later, which get canonicalized, *will* give a CSSUnitValue with a "deg" unit.)

> But, like I said, this is the "easy" case. It's verbose, but at least workable. It gets a lot more complicated if any of the numbers can be CSSMathValue,
> [snip details]

I'm a little confused about what the concern is here.

You'll only get a complex function out of Typed OM if (a) the author wrote those in CSS and you're getting a *specified* value (since we don't simplify until computed-value time) or (b) you're looking at a computed-time value and it specifically uses a value in a math function that can't be converted into a canonical unit yet.

In neither of those situations can a JSColor API even represent the value at all. This isn't a matter of one API being more complicated than the other; the value *itself* is complicated, Typed OM can represent it, and a JSColor API wouldn't be able to. JSColor would just punt.

However, if you're *not* using a value that invokes these complicated things, then CSS is guaranteed to simplify it away by computed-value time, and TypedOM will present you with a plain CSSUnitValue object for all the channels. So, as long as JSColor is *capable* of representing the value, TypedOM will represent it in the exact same way (save for the `.value` bit).

And if we're talking about using this API to create and work with colors *directly*, then there's *no chance* those complex situations will occur either. An author would have to go out of their way to manually create the Typed OM objects representing those functions, and that's their own fault at that point. ^_^ So in this situation TypedOM and JSColor would be the same, too.

> Because this is Typed OM and needs to closely represent CSS syntax, there is a number of subclasses that each have a different API. sRGB colors can either be CSSRGB or CSSColor. In the first case their red coordinate is read via color.r.value, in the second case via color.channels[0].value. It's not even clear to me if they use the same ranges. Any code that needs to be able to handle any color value needs to do a lot of annoying conditional branching about what class they have.

As far as I can tell, this is a concern for a JSColor too, isn't it? If you're working with color values that are in different spaces, they'll present their own APIs - `.r`/`.g`/`.b` vs `.h`/`.s`/`.l`, etc.  If you want them all in the same space so you have a consistent API, you can convert them to a single space, and Typed OM values make that easy as well with `.to()`.

(Contrast that with any existing CSS color handling, which'll returns strings in particular spaces and no easy way to request a particular space, so you *do* have to do any changes yourself.)

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

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


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

Received on Wednesday, 19 May 2021 19:28:56 UTC