Re: [media] adding autoplay requirements to requirements doc

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