[whatwg] Full screen for the <video> element

[Ian Hickson]

On Fri, 26 Oct 2007, Dave Singer wrote:
> > > 
> > >  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.

In general I agree, but when we don't have a single solution we can think 
of that's any good, it seems highly experimental (and thus inappropriate 
for HTML5) to have the requirement in the spec.


On Thu, 25 Oct 2007, Jonas Sicking wrote:
>
> 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.

Neither can I.


On Fri, 26 Oct 2007, Dave Singer wrote:
> 
> 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.

Actually, lack of imagination on everyone's part _is_ a good reason to 
leave out a feature. We shouldn't be using HTML standardisation as a 
research lab, we should be standardising things we know work.


On Thu, 25 Oct 2007, Jonas Sicking wrote:
> 
> 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.

Right.


On Thu, 25 Oct 2007, Greg Houston wrote:
>
> Roughly, one solution might be:
> 
> The user is playing a video within a web page. They click on full screen 
> mode. The toolbar, status bar, menu bar, and so forth are removed, 
> leaving just the title bar and close, minimize, and restore controls. If 
> there is no movement of the mouse for 2-5 seconds the title bar 
> disappears. With movement of the mouse again, the title bar reappears. 
> If the user clicks on the close control, the window returns to its 
> original state while continuing to play the video within the page. Also, 
> If the video comes to an end the window returns to its original state.
> 
> If you don't want the title bar to control closing full screen mode, the 
> browser could display a special video bar during full screen mode 
> directly underneath the title bar. This bar could have play controls on 
> it. Again, the video bar (as well as the title bar) would disappear 
> after so many seconds of no mouse movement.
> 
> In addition to redisplaying the title bar (and potentially the video 
> bar) on mouse movement, it might be helpful to have a way to overlay 
> play controls (pause, stop, and so forth) on top of the video at this 
> time giving the designer a way to add those controls or supplement those 
> that would be in the video bar if the video bar was implemented.
> 
> Standard hotkeys in full screen mode might be nice, e.g., space bar 
> (play, pause).

That's what the spec has now. The user has to tell the UA to go 
full-screen.


> With javascript it is already possible to make full screen web pages. If 
> advertisers were going to exploit this they would have by now.

Actually, they can't, as far as I can tell.


> Standardizing full screen video mode seems like a good idea since users 
> will learn what to expect and how to navigate it. Otherwise, you 
> potentially have a 1000 different implementations of fullscreen mode 
> devised by designers requiring the end user to figure out each time how 
> to navigate that particular implementation.

You only need one implementation -- the user agent's. It just means you 
can't have little JavaScript UI to trigger it, but I think that's ok.


On Fri, 26 Oct 2007, Dave Singer wrote:
> 
> But the question remains:  should we provide standard markup to do 
> fullscreen, "since most browsers will provide an extension to do it 
> anyway", or not?  And if so, how much do we say about the security 
> issues (and what)?  And if not, how do we still need to say about the 
> security issues for browsers that do it anyway through UI, extension, or 
> both?

Through UI there's not really a security problem. Through an extension, 
that's up to the UA. We can't mention all the ways that UAs can shoot 
themselves through the foot. If an extension turns out to be good, then we 
can spec it.


On Fri, 26 Oct 2007, Jonas Sicking wrote:
> 
> I imagine what will happen is that pages will create a <video> that 
> covers the whole content area of the current window and then have some 
> mechanism that minimizes the video again.
> 
> I could see an argument for having an API that maximizes the video 
> within the content area of the current window and adds some sort of 
> browser specific UI to minimize it again.
> 
> However, it isn't clear that sites will prefer that over having their 
> users choose 'fullscreen' from the context menu (or whatever other UI 
> the browser chooses to use).
>
> Actually, the more I think about it the more I like the idea of an API 
> for "fullwindow". What do other people think?

Why do we need an API for it? Just use CSS. It's a few lines of code.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'