On Jun 5, 2012, at 3:02 PM, Ian Hickson <[email protected]> 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

Reply via email to