[whatwg] Full Screen API Feedback

On May 11, 2011, at 11:25 PM, Robert O'Callahan wrote:

> On Thu, May 12, 2011 at 4:45 PM, Jer Noble <jer.noble at apple.com> wrote:
> 
> > 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.
> 
> I'm not suggesting that the element exists in two views simultaneously, but rather that it becomes the root of a new viewport.
> 
> What does that mean in CSS terms?
> 
> Does the element cease to exist in the old viewport? If so, what would that mean in CSS terms?

I would imagine that, yes, the element ceases to exist in the old viewport.  I'm not sure what that would mean in terms of CSS.

> Having elements in the same document be in different viewports still creates all kinds of spec and implementation issues :-(.

It very well might.  The current proposal has issues of it's own though. :)

> > 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.
> 
> That is much more difficult than it sounds.  :)
> 
> Freezing the non-full-screen content is already undesirable.  The animation can take an arbitrary amount of time to complete,
> 
> Really? Why? It shouldn't take more than a second to complete, surely?

This is hypothetical, but imagine a touch-based UI where the user can "pinch" to enter and exit full-screen.  In this UI, the full-screen animation is under direct control of the user, and so can take as long as the user wants it to take.  

> > 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.
> 
> >
> 
> The current API already requires that authors listen for events that may occur in the far future.  I don't see how this event would be any different.
> 
> You mean "fullscreenchanged"?
> 
> I'm confident authors will understand that "fullscreenchanged" might fire late or never and will encounter that during testing. I'm less confident it will be obvious to authors that both "fullscreenchanged" and "fullscreendenied" might never fire and will encounter that during testing.

I'm not sure I get the distinction.  In fact, it seems to me to be the opposite. 

A) If an author calls requestFullScreen(), at some point in the future they will receive either a "fullscreenchanged" event or a "fullscreendenied" event.
B) If an author calls requestFullScreen(), at some point in the future they may receive a "fullscreenchanged" event, or not.

I'd argue that A) is easier to grasp.

> And your geolocation example actually argues the other way: the existing geolocation API includes an asynchronous error handler that is explicitly called when a request is denied.  This would be a similar if not identical use case.
> 
> I don't necessarily agree with that part of the geolocation API :-).

Fair enough.  But it is an API in relatively wide use now.  Have authors complained that the timing of the error handler is too confusing?

> > 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.
> 
> That seems non-optimal.  It would result in a very confusing user experience ("The page is requesting full screen?  But it already is full screen!"), and I doubt any authors would choose to implement it that way.
> 
> It seems rational to me: click on fullscreen, the video fills the entire window (but not the screen), and some browser UI appears to suggest going the rest of the way. Maybe that's not great, but the user experience where the app waits for fullscreendenied before filling the window sounds even worse, if that event never fires. It's also pretty bad if some passive UI appears, the user ignores it, then later notices it and dismisses it, and the video suddenly fills the window!

True, without the "fullscreendenied" event, authors will be forced to "pre-fallback" to a full-window mode.  But with the "fullscreendenied" event, they can decide whether to do that, or a more traditional post-denial full-window mode.  If one is more confusing than the other, they can prefer the less confusing behavior.  However, by withholding a denial event, the API is making that decision up front.

> Are you planning to have any kind of UI for fullscreen permission, or do these issues simply not arise for you?

That behavior will be implemented by the browser, so that isn't up to WebKit to decide.

-Jer

Received on Thursday, 12 May 2011 00:24:15 UTC