- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 20 Apr 2011 20:27:00 +0200
- To: public-html-a11y@w3.org
On Wed, 20 Apr 2011 18:24:43 +0200, Eric Carlson <eric.carlson@apple.com> wrote: > > On Apr 20, 2011, at 4:11 AM, Philip Jägenstedt wrote: > >> On Wed, 20 Apr 2011 12:08:09 +0200, Silvia Pfeiffer >> <silviapfeiffer1@gmail.com> wrote: >> >>> On Wed, Apr 20, 2011 at 5:41 PM, Philip Jägenstedt <philipj@opera.com> >>> wrote: >> >>>> If it's a problem that media starts playing without user consent then >>>> it's >>>> not enough to disable autoplay, as there will certainly be sites that >>>> use >>>> scripts to start playing. >>> >>> Yes, we agreed on that, too. But we didn't see a way to catch the >>> script-created autoplays in a simple and reliable way. >> >> The browser inevitably has to know when a video should start playing. >> At that point, one could simply not play until an asynchronous >> confirmation has been given, similar to how pop-up blockers work. >> > The problem is knowing when to block script-initiated playback and/or > ask the user for confirmation. "If play() was not called from a user > gesture handler" is an easy answer, but that break playlists, scripts > that call play() after a delay (eg. to let an animation run), etc. > Requiring a user gesture doesn't really solve the problem anyway - > someone that really wants to start playback automatically can call > play() from an event handler registered on <body> like "pop-under > window" scripts do to get around pop-up blockers today. It doesn't have to use exactly the same logic as pop-up blocking, I was mostly thinking about the asynchronous approval. As for when to ask, if nothing else works one could simply always ask and remember it per-origin to reduce the annoyance somewhat. This is assuming that playback without user confirmation is a catastrophic failure to avoid at all cost, which might not be entirely true. > We had this discussion at great length on the WhatWG several years > ago. In his "Accessibility of HTML 5 video and audio elements" blog post > [1], Bruce Lawson originally questioned the 'autoplay' attribute but > after a few days updated the post to say "I’m now reluctantly accepting > that autoplay should stay" because of Simon Pieters point [2] that: > > Removing the attribute will not make pages stop autoplaying video. > Instead they will use > script to make videos autoplay, and then it becomes harder for the > user to prevent > videos from autoplaying. (You could have a pref in the UA to disable > autoplay="".) > > The 'autoplay' attribute on the HTMLMediaElement is useful because it > allows a page authors to *request* automatic playback, but it allows a > UA to *deny* that request if a user so desires. Why would the same not > apply to a group of media elements? I have no issue with the autoplay attribute, or I wouldn't have added a user pref to "deny that request". As for autoplay on MediaController: On Mon, 18 Apr 2011 10:59:28 +0200, Philip Jägenstedt <philipj@opera.com> wrote: > I have no strong opinion, but we should have consistency such that > changing the paused attribute (e.g. by calling play()) has the exact > same effect. It's not clear to me what the spec thinks should happen > when play() is called on a media element with a controller. Also, where should the autoplay attribute be in the markup? -- Philip Jägenstedt Core Developer Opera Software
Received on Wednesday, 20 April 2011 18:27:31 UTC