[whatwg] Full screen for the <video> element

At 23:39  -0500 25/10/07, Greg Houston wrote:
>Roughly, one solution might be:
>
>The user is playing a video within a web page. They click on full
>screen mode.

You are describing something initiated by user action, which any 
browser is quite free to support.

But if that user action is mediated through HTML, or the fullscreen 
request originates in the HTML, the position is rather harder.  What 
you write below is only 'obviously' an embedded video for a few 
seconds, alas.

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?

>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).
>
>With javascript it is already possible to make full screen web pages.
>If advertisers were going to exploit this they would have by now.
>
>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.
>
>
>On 10/25/07, Jonas Sicking <jonas at sicking.cc> wrote:
>>  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
>>


-- 
David Singer
Apple/QuickTime

Received on Thursday, 25 October 2007 23:26:35 UTC