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 allow for looping of the grouped resource. This is inconsistent with what is possible on individual media elements and also inconsistent with what is possible on in-band multitrack media resources. The same behavior that an in-band multitrack resource exposes on looping needs to also be possible on a grouped multitrack resource. Therefore, we request addition of a loop IDL attribute on the MediaController object. When it is set to true, playback on the grouped multitrack must restart after all slave elements have ended. It is set to true when at least one of the media elements in the group have a loop IDL attribute that is set to true, false otherwise. Alternatively, it would also be acceptable to set it to true only when all of the media elements in the group have a loop IDL attribute that is set to true, though that seems overly verbose.
Hate to pull this tired line, but: What's the use case? Since it is an IDL attribute that's being suggested, it requires using scripts. The only benefit over using .onended = function() { this.currentTime=0; } is gapless looping, which seems to really be of rather marginal importance. In short, I don't think it's something implementors should be spending time on. Other than that, what behavior is expected when the resources which loop are not of the same duration? Before looping was removed from the spec, it was to loop each clip over its own duration. This is problematic when seeking if the exact duration (down to the sample) isn't available before decoding the end of the resource. The duration metadata in the file header isn't always of sufficient precision.
The model that I always have towards the Controller is that it should expose the same kind of behaviour that in-band multitrack exposes, too. So, if a resource (/track) is shorter than that combined timeline, it will only loop (restart) when the end of the combined timeline is reached. It is indeed a convenience feature over using .onended = function() { this.currentTime=0; } and allows having a loop feature on controls, where the controls control the combined resource. At the same time it also has the side effect that the @loop attribute on the individual elements stops controlling looping of the individual elements and is instead applied to the combined resource, making sure that the timelines stay in sync as though this was in-band multitrack.
Silvia, are you saying that a loop attribute on any of the slave media elements should cause the whole group to loop? In that case no IDL attribute on MediaController is needed, right?
(In reply to comment #3) > Silvia, are you saying that a loop attribute on any of the slave media elements > should cause the whole group to loop? In that case no IDL attribute on > MediaController is needed, right? It would represent the aggregate loop state from the individual slaves, i.e. if one has a @loop attribute or an IDL loop=true, then the aggregate loop state is true.
(In reply to comment #4) > (In reply to comment #3) > > Silvia, are you saying that a loop attribute on any of the slave media elements > > should cause the whole group to loop? In that case no IDL attribute on > > MediaController is needed, right? > > It would represent the aggregate loop state from the individual slaves, i.e. if > one has a @loop attribute or an IDL loop=true, then the aggregate loop state is > true. Oh, so it's read-only then?
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Silvia, are you saying that a loop attribute on any of the slave media elements > > > should cause the whole group to loop? In that case no IDL attribute on > > > MediaController is needed, right? > > > > It would represent the aggregate loop state from the individual slaves, i.e. if > > one has a @loop attribute or an IDL loop=true, then the aggregate loop state is > > true. > > Oh, so it's read-only then? Yes, read-only also.
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: Not supporting this was intentional: completeness is not a use case, and only makes sense when it would be simpler than the alternative, which is not the case here.
mass-moved component to LC1