- From: Robert Burns <rob@robburns.com>
- Date: Tue, 3 Jul 2007 17:33:44 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Sander Tekelenburg <st@isoc.nl>, public-html@w3.org
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 UTC