[whatwg] Full Screen API Feedback
Gregg Tavares (wrk)
gman at google.com
Fri May 20 19:07:13 PDT 2011
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
> 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
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.
> Jer Noble <jer.noble at apple.com>
More information about the whatwg