W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] api for fullscreen()

From: Henry Bridge <hbridge@google.com>
Date: Mon, 1 Feb 2010 09:42:36 -0800
Message-ID: <22498dfb1002010942m251fe833pedb6428d4e68924@mail.gmail.com>
>
>
> 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.htm>
Received on Monday, 1 February 2010 09:42:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC