- From: Oliver Hunt <oliver@apple.com>
- Date: Sat, 4 Oct 2008 03:36:48 -0700
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