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.
