On 15/04/07, Maciej Stachowiak <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]