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

Re: handling fallback content for still images

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 3 Jul 2007 16:09:20 -0700
Message-Id: <4A230A4D-7C58-4A67-8BCA-D5A66EDB9AA3@apple.com>
Cc: Sander Tekelenburg <st@isoc.nl>, public-html@w3.org
To: Robert Burns <rob@robburns.com>


On Jul 3, 2007, at 3:33 PM, Robert Burns wrote:

>
> 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.

<audio> and <video> are very similar to each other, but very  
different from <canvas>, and both are very different from a plain old  
<object>.

> 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.

That would certainly be nice, but embedded content is one of the  
cases where it is hardest to support general-purpose drawing.

Regards,
MAciej
Received on Tuesday, 3 July 2007 23:09:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:46 UTC