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

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

An ICC profile is _sufficient_, but not always _necessary_. For many conversions, it's far easier to just specify metadata about the color space and conversion code to/from XYZ, and that also makes them synchronous, whereas loading an ICC profile is asynchronous.
Most RGB spaces fall into this category.
For CMYK ones, the ICC profile is pretty much the only way.

> 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 there is. Let's take gamut mapping as an example. 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.
Granted, this may eventually become an issue for CSS as well, if we add functions to read individual components, but right now it's not.
To clarify, I do not think this functionality needs to be present in `CSSColorValue`, whose purpose is to represent the existing CSS syntax as objects. But it does need to be available on the Color API.

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

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

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

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. They need to handle them somehow, potentially creating error conditions down the line that shouldn't be there. Similarly, methods of the API itself need to handle such values somehow, complicating it both conceptually for authors and practically for implementors. Whereas a `Color` object would always come with the guarantee of actual resolved values that can be worked on.

There could be some utility in a convenience method on `CSSColorValue` that resolves its expressions based on a given context and returns a resolved `Color` object. 

> 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()`.

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

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

I'm not sure what you're asking here.

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1039#issuecomment-845052441 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 12:20:47 UTC