[whatwg] MediaController feedback

[Silvia Pfeiffer]

Hi Jer,

Feedback just on one component of your request: readyState.

The suggestion of introducing a readyState IDL attribute on the
MediaController was rejected previously:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12547 . You might want
to reopen that bug and reply to the rejection reason there.

Cheers,
Silvia.


On Thu, Nov 3, 2011 at 8:50 AM, Jer Noble <jer.noble at apple.com> wrote:
> Hi,
>
> I'm currently working on implementing MediaController in WebKit <https://bugs.webkit.org/show_bug.cgi?id=71341>, and have a couple pieces of feedback from an implementor's POV:
>
> * MediaController Playback State and Ready State
>
> The spec defines both a "most recently reported readiness state"[1] and a "most recently reported playback state"[2] which, when changed, trigger a variety of event.  Because these previous values of these states must be compared each time they are recomputed[3], we must store these values in our MediaController implementation, which is no huge burdon.
>
> However, when I was writing testcases for my implementation, I noticed that there was no way to query the current value of either the playback state or the ready state, as neither was present in the IDL for MediaController.  This makes writing test cases much more difficult, as they now much rely on waiting for edge-triggered events.
>
> In addition, there is a use case for having playbackState and readyState in the MediaController IDL.
>
> When adding a MediaController to an HTMLMediaElement, the spec does not require the media controller to "report the controller state".  (It does require that the MediaController "bring the media element up to speed" with the new controller.)  In this case, the media controller should also be requried to "report the controller state", as adding a blocking media element to a controller should probably cause the playbackState to revert to WAITING.  But if the current playbackState is already WAITING, no "waiting" event will be emitted, and the client waiting on such an event will wait forever.
>
> So I would like to propose two changes to the spec:
>
> + MediaController should expose the following attributes in IDL:
>
>  readonly attribute unsigned short readyState;
>  readonly attribute unsigned short playbackState;
>
> Exposing these attributes would have approximately zero implementation cost (at least in my implementation) as these values are stored and easily queryable anyway.
>
> + Modify the media.controller()[4] section to require that the setting the controller "report the controller state".
>
> * MediaController.play()
>
> The MediaController play() function does not actually cause its slaved media elements to play.  If all the slaved media elements are paused, the MediaController is a blocked media controller, and none will play until at least one element has play() called on it directly.  And even in that case, only the playing elements will begin playing.
>
> In addition, the "user interface" section of the spec says the following:
>
>> When a media element has a current media controller, and all the slaved media elements of that MediaController are paused, the user agent should unpause all the slaved media elements when the user invokes a user agent interface control for beginning playback.
>
> So now, an individual media control must be able to access all other HTMLMediaElements associated with a given MediaController, because there is no facility in MediaController to actually unpause all the slaved media elements.  In a previous paragraph in that same section:
>
>> When a media element has a current media controller, the user agent's user interface for pausing and unpausing playback, for seeking, for changing the rate of playback, for fast-forwarding or rewinding, and for muting or changing the volume of audio of the entire group must be implemented in terms of the MediaController API exposed on that current media controller.
>
> Except, in the case of unpausing, this extra requirement of unpausing the slaved media elements is somewhat in conflict with this paragraph.
>
> 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.
>
> Thanks,
>
> -Jer
>
> [1] http://www.w3.org/TR/html5/video.html#most-recently-reported-playback-state
> [2] http://www.w3.org/TR/html5/video.html#most-recently-reported-playback-state
> [3] http://www.w3.org/TR/html5/video.html#report-the-controller-state
> [4] http://www.w3.org/TR/html5/video.html#dom-media-controller
> [5] http://www.w3.org/TR/html5/video.html#bring-the-media-element-up-to-speed-with-its-new-media-controller
> [6] http://www.w3.org/TR/html5/video.html#dom-mediacontroller-play
> [7] http://www.w3.org/TR/html5/video.html#dom-mediacontroller-pause
> [8] http://www.w3.org/TR/html5/video.html#user-interface
>