W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] Fullscreen Update

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 19 Oct 2011 10:45:34 -0400
Message-ID: <CABirCh8sUMARDW6U0Bo5hGnveR-W-_WHjnagaBjDC4aQqP6x6Q@mail.gmail.com>
On Wed, Oct 19, 2011 at 12:40 AM, Anne van Kesteren <annevk at opera.com>wrote:

> 1) How much should UI-based and API-based fullscreen interact? To me it
> seems nice if pressing F11 would also give you fullscreenchange events and
> that Document.fullscreen would yield true. Why would you not want to give
> the same presentation via native activation and API-based activation? Of
> course when you activate it UI-wise, navigation should not exit it.


The most obvious way to write a fullscreen button is:

b.onclick = function(e) {
    if(document.fullscreen)
        document.exitFullscreen();
    else
        gameDiv.enterFullScreen();
}

If F11-fullscreen sets document.fullscreen, this breaks; enterFullScreen
would never be called.  This could be dealt with, of course (check
document.fullscreenElement == gameDiv instead), but it's a corner case that
people aren't going to test.

For native <video> controls the case seems clearer that they should work
> using this API.
>

Definitely agree with native video controls.

Is that an acceptable limitation? Alternatively we could postpone the nested
> fullscreen scenario for now (i.e. make requestFullscreen fail if already
> fullscreen).
>

Pages could still implement nesting themselves.  It'd take more work and
cooperation between elements, and wouldn't work with native video controls,
but for a site complex enough to need it that seems acceptable.

However, enterFullscreen shouldn't fail when already in fullscreen.  You
should be able to change the fullscreenElement without having to exit and
reenter fullscreen.

-- 
Glenn Maynard
Received on Wednesday, 19 October 2011 07:45:34 UTC

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