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 <[email protected]> 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 >
