<video>?There are several reasons for picking a new element in HTML5 as opposed to reusing <object>:
<object> is already very complex. We plan to fix the interoperability story, but making it even more complicated by adding APIs that only work for some type of content is not desirable. This both makes the feature much harder to understand for web authors and harder to implement for implementors (as indicated by people from Apple and Opera for instance).
<video> element is better for semantics. Since you know the element will contain video you can then easily do specific things with it.
This is quite different from XHTML2 where every element can potentially embed video using the src attribute. I suppose this approach is appealing to some people, but it makes it much more complex to provide an API as currently that API is available on all elements. And all elements would also have a drawing API (<canvas>), grid API (<datagrid>) et cetera. Maybe to solve that problem you would use the magical role attribute with values such as canvas, video and datagrid. Besides that it would be in my opinion very confusing if the API changed on an attribute value why not just use a dedicated element?
Having a dedicated element also allows attributes specific to the functionality it provides. For instance, a ui attribute is considered for the <video> element that would let authors say that they want the user agent to provide the user interface.
Is it also necessary to embed Flash videos with this new element? And which datatypes can be embedded using this element?
Some questions that came up...
I'd never thought about it from an API standpoint. I like it. A <video> element makes a lot of sense, especially since video is becoming more and more prevalent online....much like <img> has had it's own element, for good reason. This is just for straight video files, like mpg, and avi, right? Not video's embedded in flash, I assume.
Yes, as indicated by the specification the intention is that all browsers natively support the (open) Theora format. Opera already has an internal build with expiremental support for that.
But where is the <audio> element?
Why not call it <media>? The API looks to be generally applicable to audio and video. VoiceXML made the mistake of going with a <audio> element which is now starting to be used for both audio and video since the semantics generally apply to both. Perhaps the same applies here.
Yes, as indicated by the specification the intention is that all browsers natively support the (open) Theora format. Opera already has an internal build with expiremental support for that.
Why would you do that? Isn't this a bit discriminating towards other codecs that may not benefit from such intentions?
Andrew, audio is very different. For video it is important where in the page it is located. This is not the case with audio. Audio also doesn’t have properties such as intrinsic width and height, subtitles et cetera.
JeromeB, I suppose, but you want browser vendors to support the same (basic) format otherwise it’s impossible to produce content.
Anne, as webdeveloper I would definitely like to use formats that are implemented by all major browser-vendors. I just think it does not belong in a HTML-specification. I'm also wondering if this matter was discussed with different codec-developers and browser-vendors, as I can't imagine HTML-spec-writers have proper knowledge of codecs.
Andrew, I don't understand your point about a MEDIA-element. What would be the difference between the already existing OBJECT-element and a seperate MEDIA-element?
JeromeB, I encourage you subscribe to the WHATWG list if you haven’t already done so. There’s been input from implementors, codec-developers, codec-advocates and web developers. It’s all very much an open and transparent process.
That's nice to hear, I didn't expect that. I haven't been into webdevelopment lately, but I'll subscribe to the list and perhaps get myself into action again...
I don't see the benefit of using <video>. What about Flash videos? Or Quicktime? Why should some video-formats be included using <object> and others using <video>?
We already know that a source is a video, since we can use Mime-types to tell us.
I am another who thinks this approach is a mistake, and I'm frankly very surprised it is even being considered. Any kind of embedded video should use object, and the type attribute should be the sole deciding factor as to what kind of object it is. It is impossible to imagine what direction these kinds of embedded objects might take, and in the future we may see all sorts of hybrid media types that would make video obsolete.
Anne (comment #7) I would respectfully disagree with your thoughts about the non-appearance of an audio file. Just as with video, audio files require a UI (and therefore, visible placement) to start/stop/adjust volume. Also, I don't see any consideration given to captioned audio/video, either of which will require placement on the page.
The notion of captioning these files is an interesting one too; obviously we can add the captions to an HTML document, but I think some thought should be given to caption data that has been embedded in audio/video too (and I hope that whatever comes of this, full compliance to the HTML 5 spec means support for in-file captioning).
Now, I was in the 'all media, even html, should be linked in an object tag camp', and I still am, kinda, but your arguments are quite persuasive, and I won't mind if HTML5 minimizes the use of object in favour of video and audio.
IMO audio and video are more similar than different. Beyond location on the page, height and width, what is the difference? I don't follow the subtitles point -- subtitles are describing the audio. Though perhaps its not common practice to include subtitles, or captions with audio today I don't think its an intrinsic difference. But differences aside, the thing is that the video element has a nice API that applies to, and is very useful for audio-only media. I think developers would be attracted to using this for audio as well as video. Perhaps they might include "bogus" video to accompany the audio just so that they can take advantage of the API. For example, you just show the album cover while a song plays. After a while, you can imagine browser vendors caving in and letting audio-only media be used by the element. And then you have an element named <video> that applies to both audio and video. Besides once you have the ui attribute, then location, height and width apply to audio too.
What about files that doesn't fit into the video category? e.g. applet, plain text, VRML, PDF… I agree with Simon Jessey that we should "classify" a file using object element with its type attribute only. For styling purpose, we can use the class attribute, or any other attributes like the role attribute if it is more semantic.
Andrew, that might be something worth looking into. I’m sure it will be considered as other people have expressed similar concerns (and ideas). You might want to join the mailing list though to follow up.
minghong, that doesn’t address the API problem at all. Also, some file types are more important than others and deserve their own element.
I think the video element is a fabulous idea. However, I don't think it should be locked to a single format. I think it's great to mandate support for Theora so we get a common baseline, but it should be possible to embed other formats with a type attribute. And do we want Flash games embedded with video or object?
Asbjørn, no need for a type attribute to enable that. In fact, I believe it is already allowed. Flash is not a video format. Most appropriate would be either object or embed.
I think the video API can be mapped to the object element by mapping the MIME type supported by a video plugin like Real Player, QuickTime and Windows Media Player. For media that are scriptable, e.g. Flash and Java Applet, they may have another set of API, and so on for other types of media.
I think having a <video> element is a good idea. even if it is just to show the browser that the following is an non-interactive, audio-visual, not a textual representation (Plus it offers an interesting way to plug in new functionality.
http://url.d/subpage.html#video.0h32s anyone?).
I also think that would make a good differentiation between "native" markup (video, xss-web-applications) and plugins embedded with -embed- or -object-
As for audio-only - I don't see any problem offering the same UI for movies with an empty video track. To make things easier for the renderer a videotrack="0" markup in the main tag may suffice
- however what I would *really* like to see is a <widget> element that can be moved around the page, put into fullscreen mode and is allowed to manipulate certain aspects of the embedding page (like the main css) - sort of as a modernization to the iframe-concept.
Well, I can dream...