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

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

From: Simon Sapin <simon.sapin@exyr.org>
Date: Wed, 09 Jul 2014 18:47:06 +0100
Message-ID: <53BD801A.3010007@exyr.org>
To: www-style@w3.org
On 09/07/14 17:58, Tab Atkins Jr. wrote:
> On Wed, Jul 9, 2014 at 9:27 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
>> 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).

Ok for device-cmyk().

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

I still think this adds more complexity than the benefit is worth, but I 
won’t oppose it any more than this. (Since the parameter is optional.)

Simon Sapin
Received on Wednesday, 9 July 2014 17:47:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:44 UTC