This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12546 - <video> MEDIA CONTROLLER requires autoplay attribute for grouped multitrack
Summary: <video> MEDIA CONTROLLER requires autoplay attribute for grouped multitrack
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML Microdata (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on: 9452
  Show dependency treegraph
Reported: 2011-04-23 03:16 UTC by John Foliot
Modified: 2013-01-31 16:21 UTC (History)
11 users (show)

See Also:


Description John Foliot 2011-04-23 03:16:35 UTC
The MediaController object currently always autoplay without a means to control this autoplay behaviour and without consistent autoplay across all the slave elements. This is inconsistent with in-band multitrack media resources. One of the main use cases for the introduction of autoplay attributes was that this allows the UA to expose a user setting that disables autoplay behaviour, which is particularly useful to vision-impaired users who cannot easily locate autoplaying media elements.

Therefore, we request addition of a autoplay IDL attribute on the MediaController object.
When it is set to true, playback of the grouped multitrack must start once all slave elements have reached a readyState of HAVE_ENOUGH_DATA and can play through.

It is set to true when at least one of the media elements in the group have a autoplay 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 autoplay IDL attribute that is set to true, though that seems overly verbose.
Comment 1 Philip Jägenstedt 2011-04-23 09:50:51 UTC
Having autoplay as an IDL attribute rather than a content attribute strikes me as rather odd, as it still requires scripts to be used.

However, if it's true that the controller currently always autoplays (I've been unable to find this in the spec), then I agree that this is not good. I would expect the controller to start in a paused state, forcing all slave media elements to be paused. When the controller plays, all slave media elements are forced to play.
Comment 2 Tab Atkins Jr. 2011-04-23 21:51:24 UTC
The MediaController does indeed autoplay by default.  This does *not* mean that all the slaved media elements autoplay; it just means that the media controller itself is either paused (perhaps implicitly) or playing.

The "perhaps implicitly" is the important bit.  A MediaController is "blocked" (not playing) if it's paused, if any of its slaves are blocked, if any of its autoplaying slaves are paused, or if all of its non-autoplaying slaves are paused.  Note that non-autoplaying media elements are paused by default, so if you hook up a media controller to a bunch of video elements, and the UA has disabled autoplaying, then the controller itself will be blocked by default until you start playing one of the slaves.
Comment 3 Laura Carlson 2011-04-29 12:11:00 UTC
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". 

Comment 4 Ian 'Hixie' Hickson 2011-06-16 21:51:23 UTC
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:

Status: Rejected
Change Description: no spec change
Rationale: see comment 2
Comment 5 Michael[tm] Smith 2011-08-04 05:05:47 UTC
mass-move component to LC1