On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns <tensafefr...@google.com>wrote:
> enterFullscreen always returns immediately. If fullscreen mode is currently >> supported and permitted, enterFullscreen dispatches a task that a) imposes >> the fullscreen style, b) fires the beginfullscreen event on the element and >> c) actually initiates fullscreen display of the element. The UA may >> asynchronously display confirmation UI and dispatch the task when the user >> has confirmed (or never). >> > > Don't you think it would make more sense to dispatch the enterFullscreen > event only when the element actually goes fullscreen? If the user clicks the > fullscreen button, but then doesn't accept whatever options (likely a > security dialog or something) then it doesn't make sense to broadcast an > enterFullscreen event, as you'd just have to broadcast an exitFullscreen > event right away to show that the user isn't actually in fullscreen. > That was my intent in the last sentence of the paragraph you quoted. > >> The enableKeys parameter to enterFullscreen is a hint to the UA that the >> application would like to be able to receive arbitrary keyboard input. >> Otherwise the UA is likely to disable alphanumeric keyboard input. If >> enableKeys is specified, the UA might require more severe confirmation UI. >> > > This seems overly complicated. I think it would suffice to simply show a > dialog the first time a user wants to go fullscreen within a domain with an > option to "remember this choice for this domain." Then the user won't have > to jump through the hoops again when they return, but will still protect > them from random websites going fullscreen and trying to phish things. This > way blocking or restricting keyboard events isn't needed. > Those kinds of dialogs are dangerous because users tend to just dismiss them without reading. Passive (ignorable and asynchronous) confirmation works better. The enableKeys option would let authors who don't need alphanumeric input (video playback) go fullscreen with a low confirmation bar (perhaps none at all, if the fullscreen request is in a click event handler). Also consider what happens if the user focuses something on another display. > Do you then drop out of fullscreen, or just blur() the fullscreen window? > (I'd vote to leave it and just blur() it, so you can do things like watch > fullscreen video on one display and continue working in the other). > That sounds like a good idea, but I don't think it needs to be in the spec. It's up to the UA. Another thing to add in here I haven't seen discussed yet is what to show as > the background to the fullscreen element. Consider the example of a 16:9 > video going fullscreen on a 4:3 display. How do you tell the browser to fill > in the extra space around the video with black (or whatever other color you > want). Is this a custom css element? > The <video> element already letterboxes. So you'd do something like this: <div class="fullscreen" style="background:black; position:relative; width:640px; height:480px;"> <video style="position:absolute; width:100%; height:100%;" src=...></video> ... controls ... </div> Making the <div> fullscreen would override the author geometry and produce the effect you want. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
