W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Use Cases for The <canvas> Element

From: Jon Barnett <jonbarnett@gmail.com>
Date: Sun, 29 Jul 2007 21:54:26 -0500
Message-ID: <bde87dd20707291954u879ccbci82121b42b2decd5a@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:02 GMT