Re: [media] adding autoplay requirements to requirements doc

On Apr 20, 2011, at 10:10 AM, Sean Hayes wrote:

> That all makes a certain amount of sense; it would carry a little more weight if there were some language in the spec to the effect that autoplay is a request that the user agent can deny. For example,
> 
> Rather than defining autoplay as:
> " When present, the user agent (as described in the algorithm described herein) will automatically begin playback of the media resource as soon as it can do so without stopping "
> Instead define it along the lines of:
> " When present, the user agent (as described in the algorithm described herein) will; unless a user agent setting has been set indicating that immediate playback is allowed, move the media into a potentially playing but blocked state: http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#blocked-media-element which is waiting for user interaction  http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#paused-for-user-interaction "

This definition has some issues:

(a) Seems to presume that no-autoplay is the default setting; this will probably not be the case.
(b) Doesn't define what happens if immediate playback *is* allowed.

Regards,
Maciej


> 
> Sean.
> 
> 
> -----Original Message-----
> From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Eric Carlson
> Sent: 20 April 2011 17:25
> To: Philip Jägenstedt
> Cc: public-html-a11y@w3.org
> Subject: Re: [media] adding autoplay requirements to requirements doc
> 
> 
> 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.
> 
>  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?
> 
> eric
> 
> 
> [1] http://www.brucelawson.co.uk/2009/accessibility-of-html5-video-and-audio-elements/
> [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019647.html
> 
> 
> 
> 
> 
>

Received on Wednesday, 20 April 2011 19:50:50 UTC