tags:

views:

110

answers:

2

HTML5 brings or will bring <video> and <audio> tags, among others. Ever since I heard of them, and even more so after reading Why do we have an img element? and particularly Jay C. Weber's message back from 1993 I wondered: Why the heck?

HTML has had a generic media-inclusion method for quite some time now. It supports fallback to other formats and text if the author so wishes which are now needlessly duplicated in two more special-purpose tags, each for a single kind of media.

To me, both <video> and <audio> are just <object>s in disguise – or am I missing something really important here that both of them support and <object> does not?

My confusion stems from the following problem: Given a snippet as this one:

<video id="movie" width="320" height="240" preload controls>
  <source src="pr6.mp4" />
  <source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"' />
  <source src="pr6.ogv" type='video/ogg; codecs="theora, vorbis"' />
  <object>
     ... fallback to Flash object
  </object>
</video>

Couldn't it have been written akin to

<object width="320" height="240" data='pr6.mp4'>
  <object width="320" height="240" data='pr6.webm' type='video/webm; codecs="vp8, vorbis"'>
    <object width="320" height="240" data="pr6.ogv" type='video/ogg; codecs="theora, vorbis"'>
      <object>
        ... fallback to Flash object
      </object>
    </object>
  </object>
</object>

preload and controls could be given as <param> elements and I'm not quite sure how to handle the id attribute right now.

Still, is there anything that prevents browser vendors from just rendering video and audio content with the right MIME type and codec themselves instead of handing them to a plugin?

+3  A: 

<video> and <audio> tags are not <object> in disguise. See this excellent explanation of new tags. In short, HTML-5 browsers are exposing their native support for audio and video. They will play video source known to them, or fall back to good old Flash, like this:

<video id="movie" width="320" height="240" preload controls>
  <source src="pr6.mp4" />
  <source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"' />
  <source src="pr6.ogv" type='video/ogg; codecs="theora, vorbis"' />
  <object>
     ... fallback to Flash object
  </object>
</video>

Edit: MIME type may tell everything, but only after you requested a file. <object>'s are bad for HTML analysis and semantics. Does JS know MIME types?

alxx
Nothing says that `<object>` cannot mean native browser implementation. E.g. when embedding images via `<object>` you won't get prompted for a plugin download either.
Joey
Ok, if I'm getting this right, the only difference is explicit support for codecs and maybe a scripting interface (though I'm not entirely sure that `<object>` would prevent the latter).
Joey
Nothing also says that <video> must be implemented with <object> internally... Even if it is, that's browser implementation detail. As I see, biggest difference is standartization and simplified syntax (no need to remember guids or anything object specific per-browser.)
alxx
I've edited the question with a (hopefully) almost-correct variant of `<object>` nesting of your code. Simplified syntax I can see. But given how HTML looks most of the time (and given that it's generated and not handwritten most of the time as well) I don't think that's a particular strong argument. From what I gleaned of the spec you only need GUIDs if you target specific non-native ways of rendering content.
Joey
HTML clarity is a Good Thing (tm) and is certainly precious to W3C :) Also, with <object> you lose page semantics. Imagine you need to find all video and/or audio on page? Object are pain in this case.
alxx
Well, you can always imagine such scenarios, though. Imagine trying to find all 3D models on a page. Or handwritten notes(which may be embedded as canvas, images or something else that might even retain ink information and recognized plain text). I'm fairly sure there are still such cases after video or audio content have gone as mainstream as images (not on my pages, though ;)). But there are also enough cases where HTML isn't very clear or concise. Why do tables have a `caption` element but images cannot be described in a similar fashion (i.e. visible on the page and linked to the image)?
Joey
Side note: I'm not entirely arguing against you here; I see the merits but I'm still sceptical since we had most of that before ;-)
Joey
A: 

You might as well ask why there are all the <p>, <div>, <span>, <b>, <strong>, <i>, <blockquote>, etc. tags when they all are basically the same anyway. That's just the way W3C thinks. The rest of the world isn't supposed to understand it - they are way beyond us mortals anyway.

Vilx-
`div` and `p` are two different levels of structuring larger bodies of text, `strong` and `em` are different levels of emphasis. `b` and `i` have been made obsolete with CSS. They have mostly legacy implications, though and I consider specifically-targeted media inclusion a vastly different subject matter, actually. Especially in the light of a general solution that already existed (which wasn't the case for any of the elements you mention here).
Joey
@Joey - all these elements are functionally the same. The only difference is that they have different styles applied, but with a bit of CSS you can make one look like the other. In the case of `<b>` and `<strong>` you don't even have to do that. It's the same thing with two different names. Invented to make html markup look prettier.
Vilx-
Well, they are semantically different – note that a viewer with acute eyesight, a flawless browser and widely-accepted typography rules aren't the only consumers of HTML. Agreed, from that angle it may well be worth to distinguish between “Media, general” (`object`), “Media, image” (`img`), “Media, audio” (`audio`) and “Media, video” (`video`). However, that's something that the MIME type can tell alone already. It doesn't start with `image/`, `audio/` or `video/` by chance ...
Joey