On Wed, May 11, 2011 at 3:27 PM, Jer Noble <[email protected]> wrote: > > On May 11, 2011, at 3:03 PM, Jonas Sicking wrote: > >> On Wed, May 11, 2011 at 11:27 AM, Jer Noble <[email protected]> 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?
On both. And make :full-screen match no element, and document.fullScreen return false, while the first event fires. > 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. I could definitely be wrong. And I agree that if we want to go that route it should be explicitly required in the spec. / Jonas
