This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The MediaController object currently does not expose an aggregate view of the readyState of the slave media elements. It is, however, impossible for a developer to reliably aggregate the readyState from the individual slave media elements, since their states may continue to change. The media framework inside the UA is the only place where such aggregation is sensibly possible. Therefore, we request addition of a readyState IDL attribute on the MediaController object. It must represent the minimum state that all the slave media elements have achieved.
The suggestion If it is really just the minimum of all slave media elements, this is actually trivial to achieve using scripts and does not need to be
Oops, slipped on the submit button. Again: The suggestion says "the UA is the only place where such aggregation is sensibly possible", but also that the aggregate readyState is simply the minimum of all the slave elements. This would actually be trivial to do with scripts, having the UA do it doesn't provide any benefit. More generally, readyState on HTMLMediaElement is only really useful in two situations: 1. When the state after an event is ambiguous, such as in the waiting event. 2. When attaching controls to an already playing media element and need to bring them up to speed. Both cases are somewhat advanced uses of the API, and I really think it wouldn't be much to ask in such a situation that the minimum of the readyStates be calculated by scripts.
Per Martin Kliehm "although the bug-triage sub-team didn't decide on these bugs yet, John mentioned in yesterdays teleconference [1] that there are several important multimedia related bugs where he'd like to add the a11ytf keyword. There was approval". [1] http://www.w3.org/2011/04/28-html-a11y-minutes.html
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: see comment 2
mass-move component to LC1
(In reply to comment #2) > Both cases are somewhat advanced uses of the API, and I really think it > wouldn't be much to ask in such a situation that the minimum of the readyStates > be calculated by scripts. In implementing this spec for WebKit, I have become convinced that the implementation of a readyState accessor is so incredibly trivial that even if the only benefit were to keep script authors from having to calculate the minimum readyState of the slaved media elements, it would still be worth adding. But as there is no accessor in MediaController for the current slaved media elements, even doing this calculation script-side has the potential for errors. > 2. When attaching controls to an already playing media element and need to bring them up to speed. Note that, currently, attaching a playing media element to a media group does not trigger "reporting the controller state", and thus in this situation the minimum slaved element readyState and the controller readyState are not the same. As such, I'd like to reopen this bug for consideration.
For the latter case, should we change the spec to report the state?
(In reply to comment #7) > For the latter case, should we change the spec to report the state? I believe so, yes. Does that deserve a separate bug?
Nah, we can use this bug for it.
Checked in as WHATWG revision r7115. Check-in comment: Update the controller state when the current media controller changes. http://html5.org/tools/web-apps-tracker?from=7114&to=7115
Checked in as WHATWG revision r7116. Check-in comment: Expose the controller state, since implementing it is apparently easy and it can be a bit more subtle than it looks. http://html5.org/tools/web-apps-tracker?from=7115&to=7116
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diffs given above Rationale: Concurred with reporter's comments.