[whatwg] Canvas color serialisation

[Ian Hickson]

On Sun, 15 Apr 2007, Jordan OSETE wrote:
>
> 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?

On Tue, 17 Apr 2007, Philip Taylor wrote:
> 
> 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.

It's not clear to me why the author ever needs to read this value. The 
value, when set, is set by the author's code -- if you need to know what 
the value is in some more detailed way then just remember what you set it 
to (e.g. with a wrapper function). The ability to "get" this attribute is 
primarily to allow for things like:

   var old = context.fillStyle;
   context.fillStyle = 'green';
   context.fillRect(0,0,100,100);
   context.fillStyle = old;


On Mon, 16 Apr 2007, Jordan OSETE wrote:
> 
> In that case, we could detect if the application tries to set an array 
> to the properties fillStyle or strokeStyle, and if it is the case, then 
> it means that the given application is more recent than the change from 
> string to array, and we can switch to an array-like reading.
>
> An internal "colorsAsArray" flag could then be set, and any reading from 
> any color property would after that return an array.
>
> Maybe let the possibility to switch back to the original behaviour by 
> setting to a string?
>
> Note that setting any color to a zero-length array should not modify the 
> property itself, but still set the internal "colorsAsArray" flag.
> 
> Ie:
> ctx.fillStyle = [];		//sets the global internal colorsAsArray flag
> without changing the fill-color value
> alert( ctx.strokeStyle.length );//should display 4
> ctx.fillStyle[4] = 0.5;		//only affect transparency
> ctx.strokeStyle = '';		//clears flag colorsAsArray without changing
> the value
> alert( ctx.strokeStyle );	//displays either a "#xxxxxx" or a "rgba(...)"
> string depending on the alpha value

This seems way, way more complex than necessary. We really want to keep 
this API as simple as possible.


Regarding the actual case of the text:

On Thu, 10 May 2007, Nicholas Shanks wrote:
> 
> Would it not make more sense to fix the UAs. lower-case hex is horrible 
> to read.

On Thu, 10 May 2007, Anne van Kesteren wrote:
> 
> Feel free to convince the Microsoft Internet Explorer team. Then again, 
> it's not like you'd actually read the return value of .fillStyle and 
> .strokeStyle yourself anyway...

On Thu, 10 May 2007, Nicholas Shanks wrote:
> 
> I assume one would use these getters primarily when debugging a website 
> during its development, and as such they would be read by human eyes, 
> and readability is quite important in the case of debugging.  It is easy 
> to scan over DECA67 but deca67 might appear more like a variable name, 
> distracting the developer, if only momentarily.

On Thu, 10 May 2007, mozer wrote:
>
> what about alert(xxx.fillStyle.toUppercase()) ?

Given the existence of this workaround, the value of consistency across 
the platform, and the unlikelihood of changing the older parts of the 
platform, I am going to leave it as lowercase.

It's really not a big deal what the case of the attribute's return value 
is, in practice...

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'