[whatwg] Full Screen API Feedback

[Jer Noble]

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

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.

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>