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

On Jul 8, 2014, at 10:46 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Jul 8, 2014 at 5:07 PM, Peter Linss <peter.linss@hp.com> wrote:
>> I like the idea, and am all for exposing all the CSS parsing in appropriate primitive chunks. To that end maybe define a CSS.parser with a collection of parsing methods rather than a set of CSS.parseXXX methods?
> 
> Like CSS.parser.color()?

Yeah, of course that presumes that we follow up and add other parsing methods...

> 
>> A few nits about your proposal:
>> stringifiers operations can't take arguments[1],
> 
> That's dumb.  Number#toString takes an optional argument; I don't
> understand why WebIDL would prevent this.  Maybe it's because
> stringifiers are ordinarily called automatically by the language with
> no arguments?  That just means that we should require all stringifier
> args to be optional.  I'll file a bug on WebIDL for that, and for now
> just change it to a regular toString method.

You probably want to leave the stringifier and have it just return rgba (or maybe that can just be defined in prose).

> 
>> The HSLAColorInit should default to black like RGBAColorInit and HexColorInit instead of red.
> 
> I considered that, but that requires the default lightness to be 0,
> which isn't useful; we'd basically be requiring lightness to be
> specified at all times.

Yeah, ok, I get your point, it just seem odd for the defaults to not be consistent. But those defaults are more useful.

> 
>> I presume the parseColor method takes color names as well,
> 
> It takes anything that can be parsed as a CSS color (and obviously
> would throw a SyntaxError or something if it can't be parsed).

Cool.

> 
>> 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"?

Either that or only return the color name if the color matches a named color (by matches I mean to be within some narrow margin, around 8 bits of resolution). i.e. if you start with a named color and round trip it through rgb and/or hex6 values you can get the same named color back.

Since RGB values are stored as doubles I think we also need to define the rounding behavior when converting to hex6 and hex3 so that round trips are idempotent (or just define such transforms to be idempotent and leave the details to the implementation).