Re: [css-houdini-drafts] [css-typed-om] Do we need separate classes per color space? (#1034)

> Each color function has a different shape; they're generally all three/four-argument, but the arguments represent different things, and have different types. 

In terms of Typed OM, they are all `CSSNumericValue`, aren't they?

> I don't think treating them identically as a list of args helps authors - in `color.r` vs `color.coords[0]`, the latter seems substantially worse in understandability.

That's a strawman, I wasn't suggesting `color.coords[0]` to be the only way to get a coordinate, but `color.coords` to get all coords as an array is useful.
In terms of getting coordinates by name, there can be convenience syntax, e.g. `color.get("r")`. But right now, if authors want to get the list of coords generically, the only way is to manually check all possible getters, which is ...not great DX.

Also note that this design does not allow for named getters for custom color spaces even if they are named in the `@color-profile` rule, since we are moving away from exotic objects in the Web Platform. Whereas a maplike design would allow for named getters for any supported color space via `.get()` and `.set()`, and you could even allow setting/getting coords of different color spaces (e.g. `color.get("lch.l")`. 
In Color.js we actually support things like `color.lch` for array of coords and `color.lch.lightness`, but not sure if that would be feasible or even desirable in a native API.

> > Though I'm not sure how to represent the difference between e.g. color(srgb...) and rgb(...). Perhaps an additional type attribute.
> 
> I think this is a code smell that suggests the merging wouldn't be a good thing. ^_^

I could argue the same for `CSSUnitValue#unit` being `"number"` when you have a number.

> > Note that this requires adding new classes and new methods on every CSSColorValue for every single color space supported
> 
> It does, but is this a bad thing?
> 
> (I'm also not quite sure what you mean by "on every CSSColorValue" - each new color class would add one method to the superclass; instances would see it by inheritance, as usual. Is there some multiplication of methods I'm missing?)

Several reasons:

a) It's currently *very* difficult to find out the color space of a color:
```js
let space = color instanceof CSSColor? color.colorspace : Object.prototype.toString.call(color).match(/\[object CSS(\w+)\]/?.[0];
```
and that's assuming these subclasses are reflected in these objects' `[[Class]]` property (and assuming the fix in #1031 actually gets pushed). If not, it's even *more* complicated.

You *could* add a property to reflect the color space, but then you'd have multiple sources of truth.

b) It makes it **very** clunky to make manipulations of colors without changing a color's color space:
```js
// Find color space
let space = color instanceof CSSColor? color.colorspace : Object.prototype.toString.call(color).match(/\[object CSS(\w+)\]/?.[0];

color = color.toLCH(); 
color.l *= 1.2; // actual manipulation

// Back to original color space
if ("to" + space in color) {
 color = color["to" + space](); 
}
else {
 color = color.toColor(space);
}
```

This should really be one line, and is one line in literally every color manipulation library out there.

Also, converting to an arbitrary color space is really clunky too, as we can see from the example above.

c) It makes it harder for authors to polyfill Typed OM for future color functions since they cannot create objects that have a custom `[[Class]]` property.

d) It privileges the color functions over `color()` (see also my point above about named getters and custom color spaces)

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


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

Received on Thursday, 13 May 2021 11:22:27 UTC