W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] Full screen for the <video> element

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 25 Oct 2007 19:50:30 -0700
Message-ID: <472155F6.9060104@sicking.cc>
Dave Singer wrote:
> At 0:48  +0000 26/10/07, Ian Hickson wrote:
>> On Sat, 13 Oct 2007, Mihai Sucan wrote:
>>>  > >
>>>  > > Shouldn't the video API include a way to toggle full screen on/off?
>>>  > > This is a rather basic feature of videos. If it will not be
>>>  > > available, video sites will hack around missing full screen 
>>> support.
>>>  > >
>>>  > > The current spec doesn't define it.
>>>  >
>>>  > Currently, the spec recommends that user agents provide a way to
>>>  > switch the view of the video to full-screen. We can't provide a
>>>  > programatic way of doing it because it is too easily abused. (Can you
>>>  > imagine if every time you went to a new site, a full-window or
>>>  > full-screen advert played?)
>>>
>>>  Yep, that's a problem. I was also thinking along the lines of allowing
>>>  fullscreen() within non-synthetic event handlers, in a similar 
>>> fashon to
>>>  popups (just like Kornel suggested).
>>
>> Given how often popups are abused today even with those requirements, I
>> hesitate to do this. (Can you imagine if every time you clicked a link to
>> go to a new site, a full-window or full-screen advert played?)
>>
>>
>>>  If that's not a desirable solution, then other solutions, which don't
>>>  require confirmation, are not easy to find.
>>
>> Indeed (and explicit confirmation is pretty bad UI).
> 
> But you don't need to tell the browser that explicit confirmation is 
> required;  you merely need to say that, if the browser supports 
> fullscreen requests (and it may ignore them), it must be clear to the 
> user that the screen is 'filled' with the video and not his normal 
> desktop.  Yes, a dialog before is one way, but so is, for example, a 
> blinking red 10-pixel border around the screen that says "security 
> warning! do not treat as desktop!" continuously.  There are (I hope) 
> better designs. :-)  i.e. state the requirement, not the solution.

I just can't think of a solution that doesn't fall into at least one of 
these categories:

1) Some sort of user-confirmation that most users will not understand
    (such as the dialog)
2) Uses annoying ugly UI that will make no sites want to use it
    (such as a blinking red border)
3) Is unsafe
4) Will be annoying since advertisers are going to abuse it.

/ Jonas
Received on Thursday, 25 October 2007 19:50:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC