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 15:12:26 +0100
Message-ID: <op.spqpq0np602458@idlaptop02.ideadesigners.local>
On Fri, 22 Apr 2005 18:55:12 +0100, Anne van Kesteren  
<fora at annevankesteren.nl> wrote:

> As there are already implementations and implementors are not likely to  
> change it all back I don't think this is going to work, but if this  
> somehow gets through then please choose the OBJECT element instead.

I think <canvas> is the best solution.

<object> is already complex and too many ways
of defining it's contents led to poor support.

canvas doesn't belong to CSS, because CSS can't use it.
Developers would use it via object.style.canvas = 'enabled' or something
like that.
Enabling via JS IMHO doesn't work either. Just adds unneccesary code:

<div id="canvas"></div>
<script  
type="text/javascript">document.getElementById('canvas').drawable=true</script>

It has been mentioned before that UAs probably won't manage to support  
drawing
on every element, so authors would limit themselves just to something basic
like static or abslutely positioned div.


<canvas> as element has some advantages:

It would be possible to modify prototype of HTMLCanvasElement
to add functions that are missing in some implementations or
- in case of safari - find all <canvas> elements and replace
them with safari-compatible ones - that would be very difficult if canvas
was enabled via CSS or JS method.


Another problem is that it would be very useful to create images
for CSS via scripting (like rounded corners, shades, patterns),
but I don't see any elegant way of joining those two...

foo {background: url(#id_of_canvas_element);}
canvas.onlyForCSS {display: none;}


-- 
regards, Kornel Lesinski
Received on Sunday, 24 April 2005 07:12:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:22 UTC