On May 11, 2011, at 11:25 PM, Robert O'Callahan wrote:
> On Thu, May 12, 2011 at 4:45 PM, Jer Noble <jer.no...@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
