[whatwg] Comments on the <video> element

Mihai Sucan mihai.sucan at gmail.com
Sun Mar 18 14:07:20 PDT 2007


Hello!

I heav read the specification of the <video> element (16 March 2007) [1],  
and I have the following comments to make:

1. I would suggest renaming "length" to "duration", because "length" is a  
rather general term. "length" is also used for arrays in JavaScript, and  
other languages. "duration" (or simply "dur") is more specific to videos.

2. Should the type attribute be added? It would be a good hint, anchors  
have it, links have it, scripts have it, etc. Type would be useful for UAs  
running on systems with limited bandwidth and/or limited resources, they  
could choose not to download the video if the type is unrecognized.

3. Personally, I believe the native UI should opt-out, not opt-in. <video>  
element implementations should not be required to implement native UI,  
however, if authors want to have their own custom UI, then they must set  
<video ui="none"> (or something similar).

I know this element definition is intended to be used by authors who want  
to code their own user interfaces.

However, I do not believe that everyone must be enforced to create their  
own user interfaces for that. Coding your own UI should be optional.

It is a general trend to have web applications behaving as native  
applications. CSS 3 will provide web developers with features for aiding  
the development of UIs that look as native applications. It is generally  
recommeded that authors do not style HTML forms.

This is practically encouraging the development of multiple, inevitably  
inconsistent, UIs for <video>. This also has the potential of reducing  
adoption among the masses: bloggers and similar users.

I would be attracted by a <video> element that provides native UI, making  
easier for me to code the web application, while providing the users with  
real benefits. Native UIs have the potential of being customized by users  
(shortcuts, even themes, and others). One of the biggest gripes of users  
of embeded Flash videos is the lack of good UIs, lack of accessibility,  
etc.

Why whould a site like Youtube switch to the <video> element? As defined  
now, they'd have to recode the video UI, and would only make it easier for  
users to download their videos. It is generally perceived as "hard" to  
copy videos off Youtube, Brightcove and other Flash-based video sites. I'm  
quite curious, if someone could list the technical benefits for Youtube,  
according to the current spec definition.

For Youtube, a site which provides bloggers an easy way to integrate  
videos, this would prove even ... hard. Here's the simple code users have  
to copy/paste:

<object width="425" height="350">
<param name="movie" value="http://www.youtube.com/v/id"></param>
<param name="wmode" value="transparent"></param>
<embed src="http://www.youtube.com/v/id"  
type="application/x-shockwave-flash" wmode="transparent" width="425"  
height="350"></embed>
</object>

Switching to the <video> element, would require a <script> element, and  
technically, for the developers at Youtube, this would mean a lot more  
work. They script must be carefully coded so that it doesn't break the  
myriad of blog systems, etc. Blogs don't even allow scripts to be run  
(last time I heard). Say Youtube wants to do this, users themselves would  
no longer like this. "What? Am I going to put a potentially risky script  
within my site?"

If <video> elements would have native UIs, bloggers would be more  
attracted of it, and developers of video sites as well. In the above case,  
you'd only have:

<video src="http://www.youtube.com/v/id">





[1] http://www.whatwg.org/specs/web-apps/current-work/#video

-- 
http://www.robodesign.ro
ROBO Design - We bring you the future



More information about the whatwg mailing list