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

On Sun, Aug 10, 2014 at 5:37 PM, Lea Verou <lea@verou.me> wrote:
> On Aug 10, 2014, at 09:42, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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.

You misinterpreted Liam ^_^ :

> Calling K "black" in CMYK would be perfectly acceptable and would match common usage.

> c) In the long run, it’s much better to name it the right way and teach people than go along with a misconception.

Only if it's actually the "right" way.

> d) `key` is actually 2 characters shorter than `black`. I thought you were all for brevity?

Brevity is a virtue, but not an absolute one.

>> 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 have no idea what you're talking about.

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

Given what I've seen in help threads about colors in Adobe forums from
people who are working with advanced color stuff but have *no idea*
what color spaces are, I think you're wrong.

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

No, again, if making a decision one way slightly hurts authors, but
the other way massively hurts implementations, we should choose the
"hurts authors" option.  (Or look for a different option that doesn't
hurt either, of course.)

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

No, the CSSOM does not break that.  At least in Chrome, setting "red"
and then reading it back gives you "red" right back.

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

Yeah, I described that.  That's a big complication for a tiny issue,
and it's not usable by author-defined extensions.

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

I propose you actually write something out that would do this; I'm
still not sure how such a thing would work.

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

No, it's a fundamental limitation of how dictionaries are supposed to
work.  All dictionary entries are optional, so can just say
`RGBColor({r:1, g:0, b:0})` is a fully opaque red (defaulting the
alpha), or `HSLColor({h:240})` is an opaque, full-saturation blue
(defaulting saturation, lightness, and alpha).  This means you can
omit *all* of the entries (either sending an empty dict, or skipping
that argument entirely) and it just fills in all the default values.

This means we can't construct a function that takes *either* an rgba
dict *or* an hsla dict, because we can't tell which one it's supposed
to be, and thus which set of default args to apply.

You seriously can't get around this.  It's fundamentally ambiguous.

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

Ah, ok.  Again, can't do it.  What does `Color(100, .5, 1)` refer to -
an RGB or an HSL?  It's impossible to tell!

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

Again, it's not an artificial limitation, it's fundamentally ambiguous.

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

I have no idea how you can possible allow both syntaxes without having
separate classes.

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

I haven't seen anything yet.  What "above" are you referring to?

~TJ

Received on Monday, 11 August 2014 01:30:20 UTC