Re: [css-color] Exposing browser color parsing to JS

On Thu, Jul 10, 2014 at 9:06 AM, Lea Verou <lea@verou.me> wrote:
> I definitely agree that this is something that should be added, but the suggested API looks a bit clumsy and unwieldy to me.
>
> 1. So to convert from HSLA, you call fromHSLA(), but to convert *to* HSLA you need to serialize through toString("hsla")? So, to get a color’s hue, you need to call .toString("hsla") and then regex match to get the first number?! Would be much more convenient to have hue, saturation, lightness getters/setters as well. And hsl/hsla getters/setters, that return/accept an array.

You seem to have missed the asHSL() function (and related one for hex).

> Of course, serialization functions are also needed, but not sure about the toString() with arguments approach. Looking into other JS classes, this doesn't seem consistent. For example, Date includes a toString() method that is invoked automatically, as well as toDateString(), toISOString(), toGMTString() etc.

Note that the argument is optional, and has a default, so normal
stringifying will work just fine.

> 2. Why name it RGBAColor and not just CSSColor or Color?

It's not specific to CSS, so I wanted to avoid a CSS prefix (this is
similar to why we eventually settled on "DOM" as a prefix for the
geometry classes).

I used "RGBAColor" specifically because it is an RGBA color; the
default attributes exposed are for RGBA.

> What if parseColor() is used to parse a device-cmyk() color? It would just fail? That seems counter-intuitive.

device-cmyk() is RGBA-compatible.  By necessity, all CSS colors must be.

> 3. Using the Euclidean distance in the RGB space to determine color difference has been known to have VERY bad results, as RGB is not perceptually uniform. The appropriate measure is DeltaE, which would be immensely useful in a UA-provided Color class, *especially* because it’s so difficult to compute for authors (if it’s exposed through a distance() method that accepts another color). [1]

What is this in reference to?  Is this just a request for a distance
function?  It sounds like a complaint about something in the proposal,
which is confusing me.

> 4. As it currently stands, this color class merely does conversions to/from Hex/HSLA/RGBA. There are so many more things authors want to do with a Color class. For example:
>         - Getting relative luminance
>         - Manipulating colors to make them lighter/darker/etc (an interesting question here is: Do these methods modify the current instance, or return a new one?)
>         - Calculating color contrast between two colors
>         - Color interpolation
>         - Alpha blending
>         - Blending modes

Many of these I want to leave off until we figure out exactly how
we're doing them in CSS; the color() function currently in the spec is
a proposal, but we haven't committed to it yet.

Intentionally, though, the class is designed to make it easy for
authors to extend with their own code.

> 5. It might be nicer if the constructor also accepted a string, instead of having to use parseColor() for that.

Color string parsing *is* specific to CSS, which is why I placed it
over there.  Is there any real difference between "new
RGBAColor('red')" and "CSS.parseColor('red')"?

> 6. It would be nice if it’s not tied to the DOM, so that it could be included in DOM-less environments as well, like Web Workers or NodeJS, so that people can stop doing this kind of sh!t over and over again [2]. If this means that things like inherit/initial/currentColor aren't supported, so be it.

It's not tied to the DOM in any way.  What makes you think that?

~TJ

Received on Friday, 11 July 2014 04:13:52 UTC