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

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()?

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

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

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

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

~TJ

Received on Wednesday, 9 July 2014 05:46:49 UTC