Re: [css-color] Preemptive rebuttal to requests to merge the JS color classes

> On 9 Aug 2014, at 18:23, Lea Verou <lea@verou.me> wrote:
> 
> However, imagine the color variable used somewhere else, many lines farther from the instance creation, especially if the color variable has a name that doesn’t include the word “color” in it. If I saw a random accent.b or accent.r I’d have no idea what on Earth it’s supposed to represent.

I think in practice you'd never see that. In languages without operator overloading you're most likely to see all color manipulation formulas repeated 3-4 times, something like:

new.r = (old.r + accent.r)/2;
new.g = (old.g + accent.g)/2;
new.b = (old.b + accent.b)/2;

And then it forms nice r,g,b (or r,g,g: http://www.viva64.com/en/b/0260/ ;)

This becomes super annoying when you have long names that don't align that well (in Sublime Text with multiple cursors I can edit 4-line r/g/b/a formulas as easily as if it was one line, but with red/green/blue/alpha I need to restrict myself to use more fiddly block copy&paste and word jumps).

Of course it'd be less of an issue if JS was going to get some vector manipulation primitives or at least the color class itself had some way to blend colors and manipulate all components at the same time (which I suggest doing, as browsers could optimize that with SIMD).

>> Also, conversions mean that you'll often get situations where if you
>> set an integer and then read it right back you'll get a non-integer,
>> due to precision loss during the conversion.  For example, most
>> integer hue angles in HSL aren't preserved when converting to/from
>> RGB.  This isn't a huge deal, as the precision loss is far too small
>> to be noticed, or even represented internally, but it does make for a
>> clumsier interaction with the API.
> If the browser implements some sort of caching like you mentioned above, that won’t be an issue.
> Even if not, we’re talking about a language where adding 0.1 + 0.2 gives you 0.30000000000000004. I’m pretty sure anyone working with JS is used to that sort of thing.

It's not only a problem of float numeric precision. With HSL<>RGB it's just completely impossible to preserve values in some cases:

color.h = x;
color.l = 0;
color.l = 1;
color.h == ?

If the color was stored internally as hsl, then h wouldn't change. If it were RGB internally, then h would be reset to 0, even though you only modified l (because setting l=0 gives rgb 0,0,0 and that resets everything).

>> Finally, you'd have to decide which class to extend, which again means
>> you have to understand colorspaces well enough to make an informed
>> decision.
> So one wants to *extend* the Color class with a new color format, write all the calculations for it, but still has no idea what color spaces are? That person must have the weirdest case of selective knowledge ever!

That's not weird. Color is *hard*. Whenever I think I finally get it, there turns out to be something even more complicated about it :)

And nobody writes their own calculations, they just copy&paste someone else's ;) I'm guilty myself of creating "L*a*b" colors without caring what D65 is, and using unlabelled "RGB" as the source.

> In any case, if we decide to have separate classes, I’d at least argue merging the RGB-based classes. Having both RGBColor and HexColor is ridiculous, and the conversion argument is moot there, as they’re all RGB values. Imagine having different Number classes in JS for different number bases, that’s how weird this is.

Agreed on this one. Hex isn't a colorspace, just a syntax sugar. RGBColor.toString(16) ;)

-- 
regards, Kornel

Received on Tuesday, 12 August 2014 14:46:37 UTC