W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] setting canvas colors as array

From: Oliver Hunt <oliver@apple.com>
Date: Sat, 4 Oct 2008 03:36:48 -0700
Message-ID: <093379F4-A160-465E-BF00-50C42B032883@apple.com>

On Oct 4, 2008, at 3:28 AM, Anne van Kesteren wrote:

> On Sat, 04 Oct 2008 12:19:03 +0200, Oliver Hunt <oliver at apple.com>  
> wrote:
>> Ah, I was not meaning to in any way suggest that we change the type  
>> of fillStyle/strokeStyle, merely to overload the assignment  
>> behaviour to allow arrays to be used -- although i'm not sure  
>> whether there is a clean way to represent this in the idl  
>> definitions in the spec.
>>
>> Basically i would expect
>> context.fillStyle = [1,1,1,0.5]
>> alert(context.fillStyle);
>> to produce an output akin to rgba(255,255,255,0.5) or some such.
>>
>> The goal is simply to make a very common idiom (computed colours)  
>> be much more concise.  As I have said previously webkit also  
>> provides a setFillColor(r,g,b,a) method which might be preferable?  
>> (the problem with this kind of approach is that it means that there  
>> are two distinct methods to set the active colour :-/ )
>
> I think the array approach is better. Given that addColorStop also  
> exists we'd have to add three extra methods and one for each new  
> member that does something with color. On top of that, the existing  
> members are already overloaded to also take CanvasGradient and  
> CanvasPattern so it would be more consistent.

I tend to agree, although it will be icky detect and vary behaviour  
appropriately on any implementation that does not support it.

eg. the standard idiom of

if (!object.feature) object.feature = function () { ... } //or whatever

doesn't work because while you can detect an implementation not  
supporting array assignment i can't think of any way to transparently  
implement support for it in JS.

--Oliver

>
>
>
> -- 
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
Received on Saturday, 4 October 2008 03:36:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC