Re: [css-color] Exposing browser color parsing to JS

On Fri, Jul 11, 2014 at 9:55 AM, Lea Verou <lea@verou.me> wrote:
> On Jul 11, 2014, at 07:13, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Note that the argument is optional, and has a default, so normal
>> stringifying will work just fine.
> I know, but I still find it inconsistent with other JS APIs.

No it's not, it's consistent with Number#toString(), which accepts an
optional argument for the base to stringify as (defaulting to 10).

>> I used "RGBAColor" specifically because it is an RGBA color; the
>> default attributes exposed are for RGBA.
>> [snip]
>> device-cmyk() is RGBA-compatible.  By necessity, all CSS colors must be.
>
> Just because CMYK colors can be converted to RGB, doesn’t mean they are equivalent. I think there’s value in having a generic Color class, that could represent both RGBA and CMYK colors (without converting them to RGBA internally).

You're right, they're not equivalent, but they're compatible by
necessity.  Allowing CMYK to be handled separately might be useful in
the future, though.

Hmm.  Okay, say I did move the parsing to the constuctor, rather than
hanging it off of the CSS object.  Then parsing with an RGBAColor
would always produce RGBA, but we could later add a CMYKAColor object
that would parse things into CMYK attributes, so you could work in the
CMYK space without having to convert until the end (or just stringify
into a device-cmyk() function, so that if your UA handles CMYK
natively and you're not doing anything that requires RGBA-ifying the
color, you keep CMYK through your whole pipeline).

>> What is this in reference to?  Is this just a request for a distance
>> function?  It sounds like a complaint about something in the proposal,
>> which is confusing me.
> Sorry, that was in reply to another message in the thread, I just wrote them all in one email. Specifically this:
>
> On Jul 9, 2014, at 08:46, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> how about a way to get the color name for an rgb value?
>>
>> Sounds good.  Should you just round to the nearest named color?
>> "Nearest" meaning "shortest distance in euclidean RGB space, with some
>> arbitrary tie-breaking method as well"?
>
> ...but a distance method would be nice too of course :)

Ah, ok.  I'm thinking we shouldn't do keyword rounding right now
anyway, and just let it return the keyword if you have the color
exactly right (rounding the float to the nearest hex, that's all), and
return null if it's not currently set to a named color's hex value.

In the future we can add a "nearest keyword" variant that does
rounding, and then add it as a serialization option too.

>> It's not tied to the DOM in any way.  What makes you think that?
>
> It was a reply to a few other messages that suggested adding methods that accept element references as parameters, to resolve things like currentColor, inherit etc.

That's already there in the proposal - CSS.parseColor() accepts an
optional second argument that's an element, for resolving
currentcolor.  This works just fine in Workers; it's just impossible
to produce an Element, so you can't ever give a valid second arg, and
thus can't decode "currentcolor".

~TJ

Received on Friday, 11 July 2014 18:03:08 UTC