On Oct 4, 2008, at 3:28 AM, Anne van Kesteren wrote:
On Sat, 04 Oct 2008 12:19:03 +0200, Oliver Hunt <[EMAIL PROTECTED]>
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/>
