[whatwg] Full Screen API Feedback

On Thu, May 12, 2011 at 6:27 AM, Jer Noble <jer.noble at apple.com> wrote:

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


Can you describe these issues in more detail?

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

This could have side effects observable to the page. I'd prefer to
standardize exactly what happens here.

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 you mean exactly by a "new view". Depending on what you
mean, that could create all kinds of implementation and spec issues. For
example, if an element can have different style or layout in the two views,
DOM APIs that return those things become ambiguous. I would strongly object
to that.

It seems to me you could animate the transition without having multiple
concurent views. For example, "freeze" the rendering of the document in its
browser window, put the document into the fullscreen state, and display it
in a popup window that starts off matching the geometry of the fullscreen
element and zooms out to cover the screen.

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

That sounds fine to me.

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

My main concern is that with some UI scenarios there might not be a good
time to fire the "denied" event. For example, in Firefox 4 when an
application requests geolocation a popup appears, and if the user clicks
anywhere outside the popup the popup disappears but there is still UI
allowing the user to grant the request later. If we used the same approach
for fullscreen, I think we wouldn't want to fire the denied event unless the
user actually selects "no" in the popup. (It would seem confusing to deny
the request and then grant it later.) I'm wary of authors writing code that
assumes a denied event will fire and breaks when it doesn't, or when it
fires later than they expect.

For your use-case of falling back to a "full-window" substitute mode, I
would suggest Web authors automatically go into the full-window state almost
immediately after requesting fullscreen, but cancel it if the window
actually goes into fullscreen mode.

Thanks,
Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]

Received on Wednesday, 11 May 2011 19:41:41 UTC