[whatwg] canvas

[dolphinling]

On Anne Van Kesteren's blog 
(http://annevankesteren.nl/archives/2005/04/canvas-element),

Sjoerd Visscher said:
 > This should never have been an element. The best way to do this is to
 > only create a canvas interface, just like the audio interface. With
 > the interface you would have to choose an image in the document to
 > replace. Canvas has no right being an element because it doesn't do
 > anything without scripting.

Ian Hickson replied:
 > Sjoerd: You shoulda said something on the WHATWG list. :-) (Unless you
 > did? I don't remember discussing this and can't find any outstanding
 > open issues on <canvas>.)
 >
 > I don't see why an element should stop being an element just because
 > it is only useful with scripting. I expect plenty of elements in HTML5
 > to be intrinsincly linked to scripting. They're still elements. We
 > still win by having UAs be able to spot them a mile away.

Dimitri Glazkov replied:
 > I guess the real question is: how canvas is pertinent to the content
 > of the page?
 >
 > As a way to put it in perspective: Is the photo paper part of the
 > picture?


Sjoerd Visscher replied:
 > Ian: I hadn't thought of this solution before. On performance: if you
 > put a script element in the head of the document containing var
 > canvas1 = new Canvas(), UAs can initialize a canvas before actually
 > encountering the location in the document where the canvas will be
 > rendered.
 >
 > Dimitri: wrong perspective. My perspective: the canvas element is like
 > issuing a newspaper with blanks for the pictures, and adding an
 > addendum with drawing instructions.


I think I agree with Sjoerd here. Changing canvas to be applied to the 
img/object elements instead of its own element would be much more 
semantic, and would also provide better fallback.




-- 
dolphinling
<http://dolphinling.net/>