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

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. 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. 
2. Why name it RGBAColor and not just CSSColor or Color? What if parseColor() is used to parse a device-cmyk() color? It would just fail? That seems counter-intuitive.
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]
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
5. It might be nicer if the constructor also accepted a string, instead of having to use parseColor() for that. 
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.

If it’s any inspiration, here’s one of the many Color classes I’ve written for my own use recently [3].

~Lea

[1]: https://en.wikipedia.org/wiki/Color_difference
[2]: https://github.com/hybridgroup/cylon-sphero/blob/master/lib/colors.js
[3]: https://github.com/LeaVerou/chroma-zone/blob/gh-pages/color.js

Lea Verou ✿ http://lea.verou.me ✿ @leaverou







On Jul 8, 2014, at 02:27, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> One of my coworkers brought my attention to
> <http://code.stephenmorley.org/javascript/colour-handling-and-processing/>,
> a library that does basic color manipulation and
> parsing/serialization.  I've seen this sort of thing multiple times,
> and even wrote my own (<http://www.xanthir.com/etc/color.js>).  I've
> also had to write a fairly complete color parser in PHP in the past.
> 
> Given that most/all of this machinery already exists in the browser,
> it's kinda sad that people have to keep reinventing it.  What would
> y'all think about introducing a bit of a helper for this kind of
> thing, that exposes all of the parsing and serialization the browser
> does, and is easily extensible so authors can use it as the basis for
> their own color-using code?
> 
> Here's my first draft of a proposal for it:
> <http://wiki.csswg.org/ideas/color-object>
> 
> Note that this intentionally does not try to interface deeply with the
> OM, as that's meant to be saved for the future OM upgrade based on
> value objects.  You can assign an RGBAColor directly to a CSS
> property, but it'll just stringify (which will have the intended
> effect).
> 
> ~TJ
>

Received on Thursday, 10 July 2014 16:06:55 UTC