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/>
