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

[whatwg] Full screen for the <video> element

From: Dave Singer <singer@apple.com>
Date: Fri, 26 Oct 2007 11:02:05 +0800
Message-ID: <p0624087ec34708e2a339@[17.84.23.140]>
At 19:50  -0700 25/10/07, Jonas Sicking wrote:
>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.

You may be right.  But a lack of imagination on my part may not be a 
good reason to leave out the feature, unless we are fairly sure that 
the feature cannot be implemented with the requirement for phishing 
protection in an acceptable way, ever, at all.
-- 
David Singer
Apple/QuickTime
Received on Thursday, 25 October 2007 20:02:05 UTC

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