Re: handling fallback content for still images

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  

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


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