[whatwg] Full screen for the <video> element

[Jonas Sicking]

Dave Singer wrote:
> 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.

I'd say it's the other way around. We shouldn't include features that we 
can't think of a way to implement them.

/ Jonas