W3C home > Mailing lists > Public > www-style@w3.org > August 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 12 Aug 2014 08:15:53 -0700
Message-ID: <CAAWBYDCNo2gRFPb6MSMMN2okgU=ztUPX1V5i7qcyYvMdou_CqQ@mail.gmail.com>
To: Kornel <pornel@pornel.net>
Cc: Lea Verou <lea@verou.me>, www-style list <www-style@w3.org>
On Sat, Aug 9, 2014 at 5:04 PM, Kornel <pornel@pornel.net> wrote:
>>> 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).

Note that this same issue exists in the color() function. I addressed
it by defining that the color() function manipulates a *five*-tuple of
r, g, b, a, and h, so you can set saturation to 0, or lightness to 0
or 1, and then change them back to a chromatic value and maintain the
hue you started with.  (There's an example of this in the spec where a
manipulation effect, for some starting colors, passes through an
achromatic color, but color() maintains the hue and pops out the right
answer at the end.)

So yeah, handling multiple coordinate spaces well is tricky due to the
presence of singularities like that.

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

I'm also definitely guilty of that.  Last time I did it I at least
*attempted* to look up some of that data, and documented the observer
and luminant that I ended up using, but I don't really understand what
they mean.

And I'm still not sure whether I'm working in linear or
gamma-corrected RGB, and which I'm *supposed* to work in for these
calculations.

Colorspaces are *hard*.

~TJ
Received on Tuesday, 12 August 2014 15:16:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 August 2014 15:16:42 UTC