- From: Mihai Sucan <mihai.sucan@gmail.com>
- Date: Sun, 18 Mar 2007 23:07:20 +0200
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
Received on Sunday, 18 March 2007 14:07:20 UTC