[css-typed-om] CSSColor should use indexed properties, not .channels

[tabatkins]

The non-generic color functions have their channels exposed as named properties, making it easy to manipulate them. CSSColor, however, has its (unnamed) channels instead exposed as an array hanging off of the .channels property, making them longer to access.

I should just make those channels be indexed properties.

(Brought up by Lea in #1034 (comment))

[LeaVerou]

Not sure I follow. You mean like color[0], color[1] etc? If so, does that mean CSSColorValue would be iterable?

[tabatkins]

Yup, that's what I mean. CSSColor would be iterable, yes. (Not CSSColorValue, the superclass.)

I was just wondering, tho - you seemed to indicate in the linked thread that it's valuable to be able to obtain the channels of any color as an array. Is this something we should support? It's pretty easy; I'd just add indexed properties to all the color subclasses, and then you could do [...color] to get the channels out.

[LeaVerou]

I'm not sure about this, what other Web Platform objects mix indexed properties with named properties? I think it's pretty rare (regex matches being the only one I can think of), but I might be missing something!

And yes, if it's iterable, you can just do [...color], no need for any special support.

[tabatkins]

(I assume you're objecting to the idea of the non-CSSColor classes having indexed properties, tho it's not entirely clear. If you're concerned about CSSColor having indexed properties as well, could you elaborate?)

Plenty of classes with indexed properties also have some methods or attributes; that's not unusual. I'm already doing it in a few places in Typed OM, in fact.

I think having some internal state being reflected in two different ways (indexed property and named attribute) is somewhat novel, but I doubt it's unheard of. (At bare minimum it's probably done for some legacy names.) It's not weird implementation-wise, tho; IDL attributes are always actually getter/setter pairs for the internal data, and having two things access the same internal info is fine.

You already do this in Color.js, afaict, right? color.hsl[0] and color.hsl.h are both allowed.

[LeaVerou]

I'm not objecting to anything, I'm just a little cautious and would like more data.

Plenty of classes with indexed properties also have some methods or attributes; that's not unusual. I'm already doing it in a few places in Typed OM, in fact.

It would be useful if you could list some of these examples outside Typed OM.

You already do this in Color.js, afaict, right? color.hsl[0] and color.hsl.h are both allowed.

Yes, though I'm not sure that would be a good idea for a native API, especially an extensible one, where new color spaces can be added.