[whatwg] The issue of interoperability of the <video> element

[Jeff Fohl]

Forgive my intruston, as I have been a lurker on this discussion for some
months, and some of the discussion often goes over my head. This may have
been proposed (if it has, I apologize for wasting your time), and perhaps I
do not fully appreciate the implications - but perhaps a solution would be
to require the <video> element to include a "codec" URI as an attribute?
This way, any codec could theoretically be used, and new ones could be added
as things evolve. The markup would then be something like this:

<video codec="mp4 <http://codecs.apple.com/mp4>" src="myvideo.mpg"></video>

or

<video codec="theora" src="myvideo.the"></video>

The codecs would be contained in a special file that the browser manages.
Users could update, add to, and manage their list of codecs by using a
contol panel. For new codecs on the scene, a URL in the codec attribute
would point the browser to a specific place on the internet where the new
codec may be downloaded. This new codec would be cached (the browser would
in this case identify the codec by the URL string), so it does not need to
be repeatedly downloaded. The only trick here is that those organizations
that wish to introduce new codecs would have to implement their codec URL in
such a way as to make sure that the browser downloads the proper codec for
the platform (OSX, WinXP, Vista, Linux, etc.) - so they would need to do
some browser sniffing and offer up the proper codec to the browser based on
its host platform.

An example of this alternate method would be:

<video codec="http:/codecs.apple.com/quicktime" src="myvideo.mpg"></video>

The codec attribute could also be indicated in the stylesheet so you don't
need to write the codec attribute for each reference on your site.

- Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070625/0bf863d9/attachment-0001.htm>