- From: dolphinling <dolphinling@myrealbox.com>
- Date: Wed, 20 Apr 2005 11:17:11 -0400
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/>
Received on Wednesday, 20 April 2005 08:17:11 UTC