[whatwg] api for fullscreen()

Henry Bridge hbridge at google.com
Mon Feb 1 09:42:36 PST 2010

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

I know it's not the biggest concern right now, but I thought it's worth
pointing out: on mobile touchscreen devices this hint does nothing as the
site can spoof the keyboard as well.  I don't see any harm in this hint, but
I'd say the focus should be on ensuring it's clear to the user what's going
on in either case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100201/f2b3c998/attachment-0002.htm>

More information about the whatwg mailing list