Re: Use Cases for The <canvas> Element

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