[whatwg] Canvas suggestions

[Philip Taylor]

On 15/04/07, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Apr 15, 2007, at 11:15 AM, Jordan OSETE wrote:
>
> > Color / style:
> > --------------
> > Reading colors can be complex. Right now it returns a string either
> > in the form #xxxxxx or rgba(...), depending on the alpha value. It
> > means the reader must be able to parse both, because he never knows
> > if the color's alpha is 255 or less. Maybe always returning rgba()
> > would be easier to parse? Or a second property wich would return an
> > array of the integer/float RGBA values when read?
>
> Changing the property would be a compatibility risk, but

I'm not sure what the rest of your sentence would have been, but I
expect the compatibility risk would be minor (though I would be much
happier if there was some evidence either way).

Since parsing strings in JS is not entirely trivial, I think it would
be nicest if the colours were returned as an array [r,g,b,a] (range
0-255), similar to getImageData. Assignment would accept any CSS
colour string, or an [r,g,b,a] array, or a
CanvasGradient/CanvasPattern. Existing code that does "var c =
ctx.fillStyle; ...; ctx.fillStyle = c" would not be affected - only
code that parses the returned colours would be affected, and I can't
think why anybody would want to do that, so I'd guess it's pretty
rare.

Anybody parsing colours has to be very careful anyway, since
implementations disagree - Opera 9 returns "rgba(0, 0, 0,
0)"/"#AABBCC", Safari 2.0.4 returns "rgba(0,0,0,0)"/"#abc" (maybe
changed in newer versions?), Firefox 3 returns "rgba(0, 0, 0,
0.0)"/"#aabbcc", and the spec currently says "rgba(0, 0, 0,
0.0)"/"#AABBCC". If the spec was changed, the situation might not be
worse - old implementations would still be incompatible with the spec,
and you'd still have to test in the browsers you want to support to
discover how they're doing it differently, but at least the future
implementations would be much easier to use.

-- 
Philip Taylor
excors at gmail.com