[whatwg] Full Screen API Feedback

[Jer Noble]

On May 11, 2011, at 3:03 PM, Jonas Sicking wrote:

> On Wed, May 11, 2011 at 11:27 AM, Jer Noble <jer.noble at apple.com> wrote:
>> 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.
> 
> Couldn't you simply define that "fullscreenchange" is fired after the
> fullscreen is cleared, but still fire it on the element which used to
> be the fullscreened element. It's nicer for authors to not have to
> deal with two events.

That takes care of one case.  But for the case where the full-screen element changes due to requestFullScreen() being called  while already in full-screen mode, which element should you fire the fullscreenchange event at?  The first or the second?  Or both? 

This would be made much clearer if the element which lost "current full-screen element" status received one message, and the one gaining that status received another.

If requiring authors to deal with two event names is too cumbersome, (which I'm not sure I agree with) perhaps a new Event type is in order.  Something like FullScreenEvent.targetEntered and FullScreenEvent.targetExited (or similar) would also solve the problem.

>> 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.
> 
> Wasn't the idea that if the user denies the fullscreen request, the
> browser can still "full-window" the element inside the normal browser
> window, thus taking care substitute for the website?


Was it?  It doesn't seem to be in the proposed API document.  And absent any explicit requirement that the browser also implement a "pseudo-full-screen" mode, I think that the above event is still necessary.

-Jer

 Jer Noble <jer.noble at apple.com>