W3C home > Mailing lists > Public > www-style@w3.org > July 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 9 Jul 2014 09:58:48 -0700
Message-ID: <CAAWBYDBvQKtKggV+ECON5cCZrA4q8J_ad1DVXwpmwYKZmE1enQ@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: www-style list <www-style@w3.org>
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

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.

Received on Wednesday, 9 July 2014 16:59:36 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:42 UTC