W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2005

[whatwg] Canvas element - Keep It Simple

From: Kornel Lesinski <kornel@ldreams.net>
Date: Sun, 24 Apr 2005 16:44:15 +0100
Message-ID: <op.spqtz1af602458@idlaptop02.ideadesigners.local>
On Sun, 24 Apr 2005 16:14:29 +0100, Jim Ley <jim.ley at gmail.com> wrote:

> Neither can HTML - it's always blank unless script is supported, so by
> that argument, Script, and only Script is the appropriate place.

It needs to be in DOM. If every element could be made canvas by script,
each DOM element would have to implement neccessary interface.

<canvas> limits this support only to certain elements and lets
browsers attach neccesary styling and behaviour beforehand.

> You've made these seem bloated, but you're ignoring the fact that the
> only "extra" code in that example is the .drawable=true - if that
> really is a problem, then it would be trivial to not require it and
> just allow drawing to start on top of any element.

Drawable <img> is pretty easy to implement (change to internal bitmap),
but drawable <div> might be really difficult (additional overlay of  

>> It would be possible to modify prototype of HTMLCanvasElement
>> to add functions that are missing in some implementations or
> The existence of an HTMLCanvasElement prototype is not standard
> currently

It's in current draft, with width/height properties and getContext method.

> - are you suggesting that the Web Application specification
> should require the prototyping of these objects? I would be very
> much opposed to this, requiring a particular coupling to javascript is
> not a good idea.

But such coupling is already there for every current form element.
Prototypes are required by ECMA script already.

regards, Kornel Lesinski
Received on Sunday, 24 April 2005 08:44:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:40 UTC