[whatwg] api for fullscreen()

>
> 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.




> 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.



> In principle a UA could support multiple elements in fullscreen mode at the
> same time (e.g., if the user has multiple screens).
>

That sounds complicated, but brings up the good point of how to choose which
screen to "go fullscreen" on. I'd recommend going fullscreen on the same
monitor that the element going fullscreen inhabits. (if there's overlap, I
suppose you'd have to calculate which display contains most of the element).
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).


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100128/7b981bc7/attachment.htm>

Received on Thursday, 28 January 2010 20:11:50 UTC