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

Would the intention be that this ultimately gain access to the upcoming CSS
colour-manipulation functions in L4? I generally find that it's primarily
necessary to parse colours as such when further manipulation is required --
for example, to lighten, darken, or find the best contrasting colour
(white/black -- via YIQ) for text. Or would it be expected that authors add
such functionality by adjusting RGBAColor.prototype?

Barry van Oudtshoorn
http://barryvan.com.au/
bvanoudtshoorn@gmail.com


On Tue, Jul 8, 2014 at 7:27 AM, 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
>
>

Received on Tuesday, 8 July 2014 00:30:05 UTC