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

On Aug 10, 2014, at 09:42, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> If you dont' know what type your object is, relying on the name of the
> property as a reminder really isn't sufficient.  Use better naming
> standards.  I don't consider this a reasonable counterargument.

My point was that seeing the property name far from the instantiation makes it hard to understand what the property does. Even color.b +1= 10; is cryptic on its own. color.blue += 10 is not.

> Valid, but these syntaxes have precedent, given the single-letter
> names of the channels *in the names of the functions/classes*.
The only precedent is that the color models are acronyms with these letters. I’ve never heard anyone refer to red as R, or green as G in practice.

> As I've argued, "key" is confusing and non-obvious, and others have
> said that interpreting it as "black" is fine.
a) Even if we call it black, the B in HWB stands for blackness.
b) Correct me if I’m mistaken, but it seems that “others” in that case is just one person, that is not even in the WG. Liam for example was not ok with it either.
c) In the long run, it’s much better to name it the right way and teach people than go along with a misconception.
d) `key` is actually 2 characters shorter than `black`. I thought you were all for brevity?

> Using a named subobject is a decent way to disambiguate, but still
> several characters more verbose than otherwise necessary.  I'm still
> not sure *why* we'd want to do a merge.
Not sure why you’re not sure, it has been mentioned several times both by me and others. Because the underlying data model is the same in all of them: RGB. They’re just coordinate transformations.

> The L in Lab is for "lightness".  There are a number of functions
> closely related to HSL/HSV that clash in similar ways.
The L in Lab doesn’t clash with anything, as Lab is a different color space that wouldn’t be in the RGBColor class anyway.

> No, why do you think I said anything like that?
Because you’re suggesting having HSLColor and CMYKColor on the same “level” as if they’re both equally different from RGB.

> I'm not sure why the average author would have any reason to know that
> CMYK is different from RGB, but HSL isn't.  If anything, CMYK and RGB
> seem more closely related, as they're both color syntaxes where the
> channels are individual colors; HSL seem like a completely different
> beast.
The average author doesn’t care for CMYK. Authors interested enough in printing colors properly that would go as far as specifying CMYK colors are very likely to know.

>> Implementation complexity should not affect UI design (and APIs are effectively a UI, where authors are its users).
> 
> UAs are below authors and users in the hierarchy of constituencies,
> but not *infinitely* below.  Their concerns still matter.
Of course they matter, as long as such decisions don’t negatively impact authors.

> Floating point math is weird, yes, but *numbers*, by themselves,
> aren't.  Integers, especially, are always precise until you hit very
> high values.  Fractional values are also round-trippable, so "foo.x =
> y; foo.x == y;" will always return true for numbers.
The CSSOM itself breaks this. E.g. e.style.backgroundColor = 'red'; e.style.backgroundColor == 'red' // false
Sure, they’re not numbers, but does it matter?

>  This proposal
> would break that invariant, which seems like a bad idea if we can
> avoid it.
In consecutive HSL calculations, browsers can avoid it with caching, dynamic type switching etc. If you modify RGB in the meantime, you don’t expect the values to stay the same anyway.
To explain: Browsers could maintain an internal array of values and an identifier of what color model is used. Consecutive HSL calculations would not change the type, and therefore the values would stay the same. 

> I'm not sure what such a thing would look like.
Something like Color.extend('hsv', function hsvToRGB, function RGBtoHSV, [coordinateNames]);

(that’s just off the top of my head, in practice it would be much more elegant and would potentially require more info, e.g. ranges)

>> Apart from that, it could also accept object literals,
> 
> No it can't, for the reason I just stated.
That sounds like a WebIDL limitation that should be fixed. 

>> RGB(A) values,
> 
> What are these?  Instances of a color class?  Yes, that's already
> possible, and will continue to be regardless.
Arguments (3-4).

>> a single array with RGB(A) values
> 
> No it can't, for the reason I just stated.
See above re:WebIDL.

>> 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.
> 
> Some people are more comfortable working with RGB in the [0-255]
> range, and others prefer the [0-1] range.  We have syntaxes for both,
> so I don't see why we shouldn't offer both possibilities to people in
> JS too.
I’m not opposed to that (although it seems a bit redundant), but making them separate classes is going too far.

> And finally, note that these are just rebuttals to any explanations of
> why we should merge the color classes.  I still haven't seen a good
> reason provided as to *why* we should merge classes.
See above.

~Lea

Received on Monday, 11 August 2014 00:37:30 UTC