[whatwg] <video> element feedback

Ian Hickson wrote:
> 
> A large portion of the feedback concerned the way that the current spec 
> doesn't have any features for native browser-provided UI.
> 
> I completely agree that on the long term this is something we need to 
> offer. However, we musn't bite off more than we can chew. There are 
> several sets of use cases, some of which require browser-provided UI, and 
> some of which need just video playback under the control of the author. If 
> we want to have this implemented well, we need to focus the browser 
> vendors' concentration on specific features. Since it is easier to 
> implement first an API then a native UI, rather than first a native UI and 
> then an API, the API has to come first. Similarly, because authors can 
> make a UI with an API but can't sanely make an API with a native UI, 
> providing an API provides authors with more options.
> 
> If LiveJournal on YouTube or some other site wanted to allow authors to 
> embed video without requiring the authors to have to deal with JavaScript, 
> they could create a page that contained just the video and video playback 
> UI, with the video URI being taken out of the query parameters of the 
> page, and then could give people markup that embedded the video using an 
> <iframe>, as in:
> 
>    <iframe src="http://video.example.com/video.html?src=http://example.net/v193"></iframe>
> 
> This would be a safe mechanism, and would be relatively easy to set up. 
> (It doesn't even require server-side support.)
> 

I must disagree with the focus on the comparatively complicated case 
(video as part of a web application) vs. the more obvious case of "I 
just want to embed a video in my web page."

If I want to embed an image in my page or blog, I just upload it 
somewhere and write:
     <img src="pretty.png">

If video is going to be considered a first-class citizen, I argue that 
this needs to be possible for video as well:
     <video src="pretty.ogg">...</video>

Currently I do not routinely post video in my blog nor on any of my web 
pages because it is non-trivial to offer it in a portable manner. Your 
proposed solution is still too much work for the casual author: unless 
some other website is prepared to help me, I have to not only upload the 
video but also prepare a second page containing some script and markup 
to implement a user-interface. (And incidentally, LiveJournal doesn't 
allow iframes to be used either. I'm not sure if that's a LiveJournal 
peculiarity or a common thing in hosted weblog systems.)

Please reconsider what you are focusing on as the "simple case". I'd 
argue that these services like Google Video and YouTube have come about 
largely *because* embedding video on a web page is such a pain right 
now. If it were just a matter of uploading the video somewhere and 
linking to it, authors would be able to do this themselves in most cases 
without the assistance of sites like YouTube, much as right now most 
authors don't need a website to help them present static images.

I won't disagree that specifying a full user interface to be provided 
along with the video element is a non-trivial task, but providing just a 
simple UI with a play/pause button and nothing else would, I expect, 
pacify most people after native UI for now. Browser vendors would be 
free to innovate their provided UIs much as Internet Explorer and 
Mozilla have with their "image toolbars".

I maintain, therefore, that the following two things should be catered 
for by the spec in addition to what's already there:
  * By default, browsers are expected to provide at minimum a play/pause 
toggle button which does not interfere with the size of the movie. (This 
implies that it must be some kind of overlay, ensuring that the size 
given by the page author is the size that the video will actually play.)
  * An attribute is provided to disable the default buttons so that apps 
providing their own branded UI don't end up with confusing interfaces.

I'd be interested to hear what is so difficult about the above. Browsers 
already do much more complicated things than this.

Received on Tuesday, 20 March 2007 14:02:15 UTC