[whatwg] Video proposals
mattraymond at earthlink.net
Mon Apr 16 04:09:43 PDT 2007
Laurens Holst wrote:
> Matthew Raymond schreef:
>>> Sure, native video playback, yay. But what has that got to do with
>>> creating a <video> element instead of using <object>. Objects can play
>>> Theora, too, you know. Natively. Just like browsers can render SVG in
>>> <object> tags, natively.
>> It's all about ease of authoring. If you were new to HTML, would you
>> want to do this...
>> | <object data="TheEarth.mpeg" type="video/ogg-theora"></object>
>> ...Or this...
>> | <video src="TheEarth.mpeg"></video>
> First of all, that isn’t so bad at all.
As I pointed out, that requires you to know the MIME type (which I
apparently got wrong), so it is that bad. However, as pointed out,
|type| is not required on some browsers.
> Second, quote from the HTML 4
> specification: “This attribute specifies the content type for the data
> specified by data
> <http://www.w3.org/TR/html4/struct/objects.html#adef-data>. This
> attribute is optional […]”.
(Idle note: It's optional when |data| is specified only.)
> So the fair-comparison snippet would be:
> <object data="TheEarth.mpeg"></object>
That's assuming the extension is provided, but the fact of the matter
is that the extension is not required, so the reality is that you might
not be able to determine if the object is even a video:
| <object data="A_001_1041"></object>
Compare that to this:
| <video src="A_001_1041"></object>
> Third, if you look at any actual embedded media, you will see that it is
> not that simple. Being able to do the first would already be a huuge
> improvement over the current <embed>-within-<object> with all parameters
> duplicated and both big amounts of plugin finder and ActiveX attributes.
> Because <video> would also need to be pluggable, you can not avoid that
> same cruft on the <video> tag as well.
I'm not exactly clear on what you're talking about here. Are you
complaining that <video> is suboptimal for an interactive Flash
presentation or something? Because I don't think that's its use case in
the first place.
> It must be pluggable, because otherwise you’ll be limited to the
> intersection of implemented codecs and file format (which might very
> well yield an empty set), and hinder third-party developers from
> creating new technologies or provide plugins for old ones so that they
> can be more uniformly supported.
Since we're not eliminating <object>, and since nothing stops UA
developers from implementing <video> in a way that simply uses whatever
video plug-in that handles the file's MIME type, I don't see the limitation.
> Fourth, those two examples are not equivalent. The former is much more
> specific. To the point of saying that even though the file has an
> .mpeg-extension, it is really video/ogg-theora.
Actually, that was a typo. It's irrelevant, though, because both
> Anyway, the current mess that is embedding via the <object> tag does not
> reflect how it is specified, and how it /could/ be.
I'm confused. What was your third solution?
>> Do you know the MIME type for Ogg Theora? I don't. I made it up. If
>> the MIME type on the object listed doesn't say "video" in it, would you
>> even know if the <object> element was for a video???
> The MIME type is optional, so the point is rather moot.
True, although the attribute |data| is not necessarily use in an
embedding context on other elements (See WF2.), so it may not be clear
to newbies what it does.
> looking up a MIME type isn’t that troublesome.
Really? What's the MIME type for VP3?
> Ogg seems to use application/ogg by the way, being the exception. It is
> interesting to read their final summary message  on the matter (which
> does mention a video/ogg-theora type), where they basically say that
> making a distinction between video and audio and images isn’t important
> enough to complicate matters by creating separate MIME types.
That's specifically when the data is in an Ogg container. Independent
of Ogg, it says the type for Theora would be "video/theora".
> With regard to determining if it’s a video or not, if you do not know,
> would that really matter?
It would if you were trying to find the markup for a video that you
want to copy-paste to your website.
> The author puts in something in the page, that
> he wants displayed there. Whether this be a still image or a video clip
> or an audio clip or a small game… that knowledge is not really important.
It is when he wants to provide his own UI for the video. It also
means that you don't necessarily get the same UI for all video types. If
you're playing Ogg Theora, you might get the controls from an embedded
version of VLC, whereas if you're playing and MPEG, you might see the
controls from QuickTime. Such UI differences can confuse the user and
make it harder for them to determine how to perform certain operations
with the video.
Requiring that plug-ins allow the browser to override the UI in the
<object> element with a native one for video would break existing
<object>-based video plug-ins, and there would be no fallback save
<embed>, which means you're limiting how many levels of fallback you can
More information about the whatwg