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

On Wed, Jul 9, 2014 at 9:27 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
> On 08/07/14 00:27, Tab Atkins Jr. wrote:
>> partial interface CSS {
>>   CSSColor parseColor(DOMString color, optional Element el);
>> };
>>
>> If parseColor is called with a color that depends on the element on
>> which it is used, such as currentcolor or inherit, but no el argument
>> was passed, throw a XXX error.
>
> Should the CSSColor return type be RGBAColor?

Whoops, yeah, lingering reference to the original name I had used.

> I’m not convinced the element parameter is useful. 'inherit' is not a
> <color>. The only <color> value that would depend on the element is
> 'currentcolor', and parsing 'currentcolor' is not that interesting.
>
> I think the Color spec should define:
>
> <color> = <rgba-compatible-color> | <device-cmyk()> | currentcolor
> <rgba-compatible-color> = (every other value)
>
> And parseColor() could parse just <rgba-compatible-color>.

Note that device-cmyk() is rgba-compatible - the (optional) final
argument defines the fallback rgba color that should be used (with
simplistic rules for calculating a fallback color if one is not
provided).

It would suck if we had a function called parseColor that couldn't
parse all colors.  I don't understand why the restriction would be
useful.  It's true that "inherit" isn't a color, but it can be the
value of the 'color' property, and I'd like to maintain the invariant
that you can *always* feed the value of 'color' into it and get a
useful result out.

~TJ