[whatwg] Full Screen API Feedback

[Gregg Tavares (wrk)]

On Wed, May 11, 2011 at 11:27 AM, Jer Noble <jer.noble at apple.com> wrote:

> WebKit is in the process of implementing Mozilla's proposed Full Screen API
> <https://wiki.mozilla.org/Gecko:FullScreenAPI>.  Basic full screen support
> is available in WebKit Nightlies <http://nightly.webkit.org/> on Mac and
> Windows (other ports are adding support as well), and can be enabled through
> user defaults (WebKitFullScreenEnabled=1).  To test the feasibility of this
> API, we have mapped the full screen button in the default controls in
> <video> elements to this new API.  The webkit-only webkitenterfullscreen()
> method on HTMLMediaElement has also been mapped to this new API.  In so
> doing, we have been able to collect test case results from live websites.
>  In this process, I believe we have uncovered a number of issues with the
> API proposal as it currently stands that I'd like to see addressed.
>
> 1. Z-index as the primary means of elevating full screen elements to the
> foreground.
>
> The spec suggests that a full screen element is given a z-index of BIGNUM
> in order to cause the full screen element to be visible on top of the rest
> of page content.  The spec also notes that  "it is possible for a document
> to position content over an element with the :full-screen pseudo-class, for
> example if the :full-screen element is in a container with z-index not
> 'auto'."  In our testing, we have found that this caveat causes extreme
> rendering issues on many major video-serving websites, including Vimeo and
> Apple.com.  In order to fix rendering under the new full-screen API to be on
> par with WebKit's existing full-screen support for video elements, we chose
> to add a new pseudo-class and associated style rule to forcibly reset
> z-index styles and other stacking-context styles.  This is of course not
> ideal, and we have only added this fix for full screen video elements.  This
> rendering "quirk" makes it much more difficult for authors to elevate a
> single element to full-screen mode without modifying styles on the rest of
> their page.
>
> Proposal: the current API proposal simply recommends a set of CSS styles.
>  The proposal should instead require that no other elements render above the
> current full-screen element and its children, and leave it up to
> implementers to achieve that requirement.  (E.g., WebKit may implement this
> by walking up the ancestors of the full-screen element disabling any styles
> which create stacking contexts.)
>

That does seem more reasonable. A conceptual way to think of it is that the
fullscreen element and all its children get a temporary z-index boost.


>
> 2. Animating into and out of full screen.
>
> WebKit's current video full-screen support will animate an element between
> its full-screen and non-full-screen states.  This has both security and user
> experience benefits.  However, with the current z-index-based rendering
> technique recommended by the proposed Full Screen API, animating the
> full-screen transition is extremely difficult.
>
> Proposal: The full-screen element should create a new view, separate from
> its parent document's view.  This would allow the UA to resize and animate
> the view separate from the parent document's view. This would also solve
> issue 1 above.
>

I'm not sure what "view" means but I can see what I think are Robert's
issues. The DOM still has to be connected and CSS still has to flow. So if I
have body(a(b(c))) and I fullscreen c then changes to CSS of body, a, and b
should all still effect c even when c is in fullscreen mode. Of course maybe
your idea of "detaching" into a separate view means doesn't imply that other
elements.

I guess conceptually I thought all fullscreen does is (1) make the browser
window fullscreen with no chrome and (2) stretch the fullscreen element to
fill that space. That implies that if I set the background color of the
fullscreen element to rgba(0,0,0,0.5) I can see back to the non-fullscreen
elements behind it.


>
> 3. "fullscreenchange" events and their targets.
>
> The current proposal states that a "fullscreenchange" event must be
> dispatched when a document enters or leaves full-screen. Additionally, "when
> the event is dispatched, if the document's current full-screen element is an
> element in the document, then the event target is that element, otherwise
> the event target is the document."  This has the side effect that, if an
> author adds an event listener for this event to an element, he will get
> notified when an element enters full screen, but never when that element
> exits full-screen (if the current full screen element is cleared, as it
> should be, before the event is dispatched.)  In addition, if the current
> full-screen element is changed while in full screen mode (e.g. by calling
> requestFullScreen() on a different element) then an event will be dispatched
> to only one of the two possible targets.
>
> Proposal: split the "fullscreenchange" events into two: "fullscreenentered"
> and "fullscreenexited" (or some variation thereof) and fire each at the
> appropriate element.
>
> 4. A lack of rejection.
>
> The current proposal provides no notification to authors that a request to
> enter full screen has been denied.  From an UA implementor's perspective, it
> makes writing test cases much more difficult.  From an author's perspective
> it makes failing over to another full screen technique (such as a
> "full-window" substitute mode) impossible.
>
> Proposal: add a "fullscreenrequestdenied" event and require it to be
> dispatched when and if the UA denies a full-screen request.
>
> Thanks,
>
> -Jer
>
>  Jer Noble <jer.noble at apple.com>