[whatwg] Full Screen API Feedback

[Aryeh Gregor]

On Thu, May 12, 2011 at 2:34 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> To be clear, we are NOT designing the UI for this thing here.  I'm not a UI
> designer.  Robert is not a UI designer.  As far as I know, you are not a UI
> designer.

Definitely correct on that last point.

> We are trying to design an API that could then have a variety of UIs built
> on top of it as needed.  The key is to design an API that does not
> overconstrain those UIs and does not generate mistaken web developer
> expectations due to them observing (or theorizing) some particular subset of
> possible UIs.

If we can figure out in advance what UIs browsers will want to use in
practice, though, that should inform what API we settle on.
Generality is not always good.  If it turns out no one wants to ask
the user before fullscreening, we don't want to design the API to
allow for that design decision, any more than we want to design the
API for canvas.toBlob() or any random function to allow for the
possibility of asking the user before allowing it to work.

So if the desired API will depend on the sort of UI browsers will want
to implement, I'd ask the UI people what UI they'd use before deciding
on the API.

> So let's try attacking the problem from that angle.  I posit that for web
> developers the following are bad assumptions and that the API should make it
> clear that they are bad assumptions:
>
> 1) Your page will automatically go into fullscreen when you ask it to
> 2) After you ask your page to go into fullscreen, you are guaranteed a
>   response within time T (for some finite T) indicating whether this
>   has happened.
> 3) You can figure out whether the user has decided that your site
>   should never be able to go into fullscreen (exposing that
>   information increases the fingerprintability of the browser, so
>   I suspect at least some browsers would not want to expose it).

Those all seem like reasonable things to avoid.  However, (3) is
probably impossible to avoid for some choices of UI.  If the UI is
like for popup windows, which seems reasonable, then either the
browser will go fullscreen right away or it won't, and you can tell by
timing.  Of course, browsers aren't obliged to maintain a per-site
blacklist on fullscreening if they don't want to.

On Thu, May 12, 2011 at 7:02 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> For this case, I think probably a better UI would be what Flash has, to
> actually go full-screen immediately but temporarily show a message telling
> the user they're in fullscreen mode and how to get out. But I still strongly
> feel that the API should be constrained so that passive confirmation won't
> break sites, in case that turns out to be necessary in the future.

What possible future scenario are you envisioning where passive
confirmation might turn out to be necessary in the future?  In
particular, Flash has allowed this for years, with 95%+ penetration
rates, so we should already have a good idea of how this feature can
be exploited in practice.  (Or at least someone at Adobe should.
Maybe we could ask them?  They have people in the HTMLWG.)