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

On Mon, Jul 7, 2014 at 7: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).
>
> ~TJ
>
>
Tab,

You note that it intentionally doesn't try to do some things because they
are meant to be saved for future things, but you propose in the draft
linked above that

"""
Authors can define their own color formats by adding a fromFoo() to
RGBAColor, a toFoo() to RGBAColor.prototype, and adding an appropriate
serialization tag to RGBAColor.serializationTypes.
""""

I was trying to establish on the conference call, why not leave this as an
explanation of how it works and just align for future extensibility here?
 I'm worried that maybe it's "half way" and doesn't add a lot of value,
maybe limits things.  For example: It can't really make CSS itself
understand something new (in terms of serializing or parsing a
stylesheet)... and should you really be able to add any old serialization
type name?  It's good for polyfilling I guess if there were a new one and,
unlikely as it sounds, not all browsers implement at the same time...
Similarly though, while it is unlikely that there would be an explosion of
these, it does run the risk that CSS can't ship something with a
particular/popular name if one picks up because it winds up with slightly
different meaning or something than a common implementation.  We've been
working on common metaphors/approaches/etc for this - an author-safe way to
plug-in and experiment and it feels like it would be nice if this was
similar and lessons learned with plugging in one thing could be
used/applied to plug in something else in CSS.

-- 
Brian Kardell :: @briankardell :: hitchjs.com