[whatwg] <video> element feedback

[Ian Hickson]

On Tue, 20 Mar 2007, Martin Atkins wrote:
> 
> 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."

The spec has since been updated to include the ability for client-side UI 
to be shown (using the "controls" attribute).


> 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.)

This is allowed, though not required.


> * An attribute is provided to disable the default buttons so that apps 
> providing their own branded UI don't end up with confusing interfaces.

This is now present (though the attribute has to be specified to have 
controls appear).


On Wed, 21 Mar 2007, Christoph Päper wrote:
> 
> Maybe it is a stupid idea, but is something like the following 
> imaginable to make a XHTML5 browser display inline video with a basic UI 
> without the need for scripting?
> 
>   <form method="MEDIA">
>     <video src="pretty.ogg"/>
>     <button type="play"/>
>   </form>

I fear overloading forms so far.


On Tue, 20 Mar 2007, Chris Adams wrote:
>
> Actually that sounds like a splendid idea to me. although I am not sure 
> about using the form tag.  what about something like?
> 
> <video src='some_file.ogg'>
>   <button type='rewind' />
>   <button type='playpause' />
>   <button type='stop' />
>  <button type='fastforward' />
> </video>

This seems redundant, why not just have:

   <video src="some_file.ogg" controls/>

...?


On Sun, 25 Mar 2007, Elliotte Harold wrote:
> 
> Why should the page be specifying the controls? Shouldn't this be up to 
> the browser?

Indeed.


On Sun, 25 Mar 2007, Chris Adams wrote:
> 
> there can always be browser defaults that take over, but by allowing 
> authors the ability to override the browsers controls will allow for the 
> flexibility of
>
> a) allowing for disabled controls (perhaps disabling fast-forward for 
> training videos)
>
> b) scripted controls (automatically pausing at various points)
>
> c) it allows for cross-browser standardization.

Indeed, scripted controls are still available.


On Sun, 25 Mar 2007, Elliotte Harold wrote:
> 
> Seems to me the user shoudl be in control here, not the author. If they 
> want to fast forward, the browser lets them.

The spec allows user agents to expose controls even when page-provided UI 
is present.


> I have no interest in enabling or even suggesting the use of the silly 
> DVD type controls where you can't fast forward through the ads or the 
> FBI notice.

Hear hear.


> > c) it allows for cross-browser standardization.
> 
> This is *not* a good thing. Browsers will and should be wildly 
> different, What works for IE will not work for a cell phone or a screen 
> reader. The point is to tell the client that there is a video, here';s 
> where to get it, and let the browser choose how best to display that and 
> present the controls that make sense in its environment.

To some extent this is true, but there is clearly demand for authors 
controlling the user experience (or at least influencing it).


On Sun, 25 Mar 2007, Kornel Lesinski wrote:
> 
> I find these annoyng myself as well, but I don't think specification 
> could stop anyone from doing that. Authors use unskippable ads in Flash 
> videos already. If <video> won't let them do the same, most likely they 
> simply won't use <video>.

At the end of the day, if the video is provided in a decodable form, the 
user can do what he wants, even if it isn't necessarily easy.


On Mon, 26 Mar 2007, Sander Tekelenburg wrote:
> 
> By leaving the user in control a UA should per definition be compliant. 
> Allowing authors to make suggestions is good. Removing control from the 
> user is not. (An individual UA could still choose to favour authors over 
> users, just like a UA can ignore anything else in the spec -- users can 
> vote with their wallet. But specifically requiring UAs to give authors 
> control on the WWW would be dead wrong.)

Agreed.


On Tue, 20 Mar 2007, Robert Brodrecht wrote:
> 
> I was somewhat concerned with the script-only controls.  Your's is a 
> neat approach if you wanted a custom, scriptless UI for the element and 
> I think it may be a good idea to have scriptless UI controls.  I don't 
> know what people would say about the form as "extra code" on the 
> minimalistic <video>.
>
> That said, if the video controls are built in via a fade-in menu like 
> iTunes video or (if they must) via a right-click menu, I think I could 
> live without scriptless UI controls.  They'd be nice, though.

It's not clear to me that scriptless controls would provide enough control 
to the author.


On Wed, 21 Mar 2007, liorean wrote:
> 
> Hmm. I'd prefer to not add an artificial method on the form element. 
> Instead I'd prefer something like this:
> 
> <button type="play" for="idref_to_video">play</button>
> <button type="pause" for="idref_to_video">pause</button>
> <button type="stop" for="idref_to_video">stop</button>
> <progress type="played" for=idref_to_video></progress>
> <progress type="buffered" for=idref_to_video></progress>
> 
> Where the buttons automatically without scripting do the equivalent of 
> the API function with the same name, and where the progress elements 
> gets it's value from the video as it plays/gets buffered.

It's not clear to me what the advantage of just moving the controls around 
would be. Typical examples of custom UI today are far more involved.


Please let me know if the current spec text is adequate.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'