[whatwg] MediaController feedback

[Jer Noble]

On Jun 5, 2012, at 3:02 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 4 Jun 2012, Jer Noble wrote:
>> 
>> This too looks good.  We already store the results when we report the 
>> controller state, so at a first glance, exposing this property will be 
>> trivial.
> 
> Make sure you're setting the attribute at the right time. There's some 
> careful jumping through hoops in the spec to make sure the attribute 
> doesn't update before the events are just about to fire.

Will do.

>>>> I would like to propose three changes to the spec:
>>>> 
>>>> + Modify the section "bring the media element up to speed with the 
>>>> new controller"[5] to require that a media element added to a playing 
>>>> media controller must begin playing, and one added to a paused media 
>>>> controller must pause.
>>>> 
>>>> + Modiy the section "controller . play()"[6] to require that the user 
>>>> agent unpause all the slaved media elements.
>>>> 
>>>> + Modify the section "controller . pause()"[7] to require that the 
>>>> user egent pause all the slaved media elements.
>>>> 
>>>> + Remove the section from "user interface"[8] which requires the user 
>>>> agent unpause all the slaved media elements, quoted above.
>>> 
>>> I don't really understand this proposal. Could you elaborate on this?
>> 
>> Sure.
>> 
>> The overall purpose of the modifications is to achieve the following: 
>> when controller.play() is called, all slaved media elements 
>> unconditionally will begin playing.
> 
> I don't think this is a good idea. If the user has paused one of the 
> slaves, and then pauses and resumes the whole thing, the paused media 
> element shouldn't resume. It should remain paused.

Why?

For one, I don't know how a user will end up pausing just one slaved media element.  It appears that won't be possible with the UA provided play/pause button, as those are required to be implemented in terms of the MediaController.  There is a non-normative line in the spec reading: 

When a media element has a current media controller, user agents may additionally provide the user with controls that directly manipulate an individual media element without affecting the MediaController, but such features are considered relatively advanced and unlikely to be useful to most users.

…But even in this (optional and "unlikely to be useful") case, the mandatory UA controls will just unpause the slaved elements the next time the user hits the UA provided play button.

With JavaScript, it's certainly possible for a page author to play() or pause() a slaved media element directly, but that author could just as easily remove the media element from the media group / media controller.

So, I don't really know what use case not resuming solves, but the general use case is made confusing by this requirement.  E.g., a page author is setting up some custom UI to control two slaved media elements:

mediaController = new MediaController()
mediaController.pause()
video1.controller = mediaController;
video2.controller = mediaController;
button.addEventListener('click', function(){ mediaController.play(); }, false);

// If developers forget this step, their play button will never work:
video1.play();
video2.play();

And then, once they discover the reason their custom play button doesn't work, a significant fraction of page authors will do something like:

button.addEventListener('click', function() {
video1.play();
video2.play();
mediaController.play();
}, false);

Which will, hypothetically speaking, break the intent of the default behavior. 

[As an aside, this exact scenario played out as a developer was asking me why their MediaController demo wasn't working.  They were quite incredulous that a call to MediaController.play() didn't actually cause their videos to play.  I think that this confusion will be quite common.]

>> Whatever use case is served by allowing a paused media element to remain 
>> paused in a playing media controller, that use case could also be 
>> achieved by removing the element from the media controller, then pausing 
>> it.
> 
> That only works if there's JavaScript doing the removing. The idea here is 
> that this should all work even without any JS, just with UA UI.

With just the UA UI, the behavior would be exactly the same, as the spec currently requires the UA provided play button unpause the slaved media elements.[1]  This would just add that requirement to the MediaController.play() method as well.

-Jer