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

On Thu, Jul 10, 2014 at 8:08 AM, Brian Kardell <bkardell@gmail.com> wrote:
> 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.

It's not "half way", because you're conflating some things that *can*
go together, but don't necessarily have to.  All this is doing is
exposing CSS color parsing.  Because it's convenient, I'm also putting
it together in a way that's easily author-extensible, based on
patterns I've used and seen others use in color libraries, so the
"basic" color stuff that CSS already covers will be handled
automatically.

Handling extensions of CSS is, as you know, much more complicated than
what I'm doing here, but we'll get to it eventually.

Regarding serialization names, the pattern I'm using is
future-compatible; we can always add new names, and if authors have
already used those, the author's ones will override.  Anyway, JS
doesn't generally go too far out of its way to handle collisions with
authors; unlike CSS, there are a multitude of ways to detect and/or
mitigate collisions if they're a problem.

~TJ

Received on Friday, 11 July 2014 04:06:01 UTC