- From: Jon Barnett <jonbarnett@gmail.com>
- Date: Sun, 29 Jul 2007 21:54:26 -0500
- To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>
- Cc: "Sander Tekelenburg" <st@isoc.nl>, public-html@w3.org
On 7/29/07, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote: > As James pointed out, one of the only alternatives was overloading img, > but that couldn't work because the implementation of canvas and img are > fundamentally different. As we know from experience with object, > overloading elements with too much functionality increases the > complexity of the implementation and increases the chance of bugs. This point about overloading <object> is a valid one. If at all, could you speak to how that applies to using <object> in place of <img> for bitmaps - particularly in one of the threads relating to fallback for <object> and the proposal of a new <picture> element? It's off-topic here, but I haven't seen anyone address the effects of overloading <object> in those threads. > Yes, SVG in HTML has been discussed as a possibility in the past on the > whatwg mailing list. It's just not particularly easy considering issues > like parsing requirements, namespaces, etc. > If one uses <object> or <iframe> to expose the EmbeddingElement API, which would expose the SVGDocument API, that avoids namespace issues, etc. Does it suffer from other deal-breaking issues, aside from the fact that SVG and <canvas> do currently have slightly different feature sets? For the purpose of replacing Flash and Java applets, SMIL, canvas, and SVG seem to have a lot of overlap. -- Jon Barnett
Received on Monday, 30 July 2007 02:54:30 UTC