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

Re: handling fallback content for still images

From: Robert Burns <rob@robburns.com>
Date: Tue, 3 Jul 2007 17:33:44 -0500
Message-Id: <464E5C84-801C-4366-886A-F3F63481FE3F@robburns.com>
Cc: Sander Tekelenburg <st@isoc.nl>, public-html@w3.org
To: Maciej Stachowiak <mjs@apple.com>


On Jul 3, 2007, at 12:47 AM, Maciej Stachowiak wrote:

> It's the differences among all three [video, audio, and canvas]]  
> and the differences relative to a regular <object> element that are  
> significant.

Taking a look at the HTML5 draft again, I'm not seeing an awful log  
of API differences on these elements: certainly not enough to clearly  
justify separate elements. The exception is the <canvas> element  
which has a lot more specialized APIs. However, I'm wondering whether  
it might be beneficial to even allow canvas APIs on other embedded  
content. This way authors could merge the two concepts: embedded  
content with programmatic drawing. I can imagine some use cases for  
that.

With that in mind, I wonder whether we can really justify the  
division of these elements on API grounds alone. As I've said before  
there may be other reasons to distinguish semantically between  
various embedded content types, and to do so in a way more  
fundamental than just <object type="">. I'm just wondering what use- 
case this separation addresses.

>> It would require DOM code to use introspection on <object>  
>> elements (how about doing canvas drawing right on the top of a  
>> video?) before assuming it will respond to video calls for  
>> instance. How is that any different from checking whether a <div>  
>> has a particular value for @class before performing some method on  
>> it?
>
> You don't have to check a <div>'s class to decide what API the  
> implementation needs to expose.

No that's true, but as I said, aside from canvas, there doesn't seem  
to be many API differences just yet.

Take care,
Rob
Received on Tuesday, 3 July 2007 22:33:53 GMT

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