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

On Mon, Jul 7, 2014 at 4:27 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> One of my coworkers brought my attention to
> <http://code.stephenmorley.org/javascript/colour-handling-and-processing/>,
> a library that does basic color manipulation and
> parsing/serialization.  I've seen this sort of thing multiple times,
> and even wrote my own (<http://www.xanthir.com/etc/color.js>).  I've
> also had to write a fairly complete color parser in PHP in the past.
>
> Given that most/all of this machinery already exists in the browser,
> it's kinda sad that people have to keep reinventing it.  What would
> y'all think about introducing a bit of a helper for this kind of
> thing, that exposes all of the parsing and serialization the browser
> does, and is easily extensible so authors can use it as the basis for
> their own color-using code?
>
> Here's my first draft of a proposal for it:
> <http://wiki.csswg.org/ideas/color-object>
>
> Note that this intentionally does not try to interface deeply with the
> OM, as that's meant to be saved for the future OM upgrade based on
> value objects.  You can assign an RGBAColor directly to a CSS
> property, but it'll just stringify (which will have the intended
> effect).

Okay, the proposal is now specced: <http://dev.w3.org/csswg/css-color/#apis>

It changed a bit from the wiki proposal, based on feedback from Lea.
She realized that an author using CMYKColor might want it to serialize
as "device-cmyk()", while the wiki version would just naively convert
it to an RGBColor and serialize as "rgba()" (or, if you indicated cmyk
serialization, would do so via another naive conversion, losing
precision).  She also pointed out that if you, for example, prefer
working with HSL colors, you'll probably want an object that actually
exposes h, s, and l attributes rather than continually doing
conversions to/from RGB.*

So, I expanded the proposal by giving all of the syntaxes a
corresponding class with attributes that match with the color
function's arguments. This required a little more indirection to make
things work automatically, particularly when authors add their own
methods or color classes, but I think it all hangs together well and
is easy to use.  I also added a section with explicit suggestion on
how to correctly add new methods and classes that will interoperate
well with the existing classes.

Note that I defined most of the operations in this spec directly via
ECMAScript.  All of the operations operate solely on exposed state, so
there's no need for magical prose on almost any of it, and doing this
automatically answers a lot of potential questions about how the
methods interoperate with author code.  I think this is OK, as most
(all?) browsers have ways of defining JS APIs in actual JS; I know
that a good chunk of JS's standard library is written in plain JS in
V8 for Blink, for example.

Feedback appreciated!

* Previously, if you wanted to increase the hue angle of a color by 20
degrees, you had to write something like:

var temp = color.asHSLA();
temp.h += 20;
color = RGBAColor.fromHSLA(temp);

That's ugly, and expensive if you're doing it a lot. Now, assuming
it's already an HSLColor object, it's just:

color.h += 20;

~TJ

Received on Sunday, 13 July 2014 23:00:51 UTC