- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 21 Apr 2011 07:33:06 +1000
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: public-html-a11y@w3.org
On Thu, Apr 21, 2011 at 4:27 AM, Philip Jägenstedt <philipj@opera.com> wrote: > 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? On one of the slaves. Silvia.
Received on Wednesday, 20 April 2011 21:33:54 UTC