Re: [whatwg] Fullscreen events dispatched to elements
What do you do when element A goes fullscreen and then element B in the same document goes fullscreen on top of it? Do you fire a single fullscreenchange event at B? Or do you fire a fullscreenchange event at A and then at B? Or something else? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen events dispatched to elements
On Tue, Jun 5, 2012 at 5:57 PM, Jer Noble jer.no...@apple.com wrote: Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Did you inform the spec editor(s) when you decided to make this change? What did they say? As it is a holdover from when we implemented the Mozilla Full Screen API proposal[1], which required that behavior, no. -Jer [1] https://wiki.mozilla.org/Gecko:FullScreenAPI#fullscreenchange_event If you implemented that proposal as-is then authors would usually need a listener on the document as well as the element, and as Chris pointed out, it's simpler to just always listen on the document. Is that true for the Webkit implementation or did you implement something slightly different? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote: If you implemented that proposal as-is then authors would usually need a listener on the document as well as the element, and as Chris pointed out, it's simpler to just always listen on the document. Is that true for the Webkit implementation or did you implement something slightly different? Sorry, you're right; we did implement something slightly different. We always dispatch a message to the element, and additionally one the document if the element has been removed from the document. So authors only have to add event listeners to one or the other. -Jer
Re: [whatwg] Fullscreen events dispatched to elements
On 06/05/2012 09:31 AM, Jer Noble wrote: On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote: If you implemented that proposal as-is then authors would usually need a listener on the document as well as the element, and as Chris pointed out, it's simpler to just always listen on the document. Is that true for the Webkit implementation or did you implement something slightly different? Sorry, you're right; we did implement something slightly different. We always dispatch a message to the element, and additionally one the document if the element has been removed from the document. So authors only have to add event listeners to one or the other. That is rather unusual behavior. I don't recall any other cases when such additional event is dispatched if node is removed from document. -Olli -Jer
Re: [whatwg] Fullscreen events dispatched to elements
On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble jer.no...@apple.com wrote: Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Why should we standardize this if we always notify the document? Is there a benefit to notifying both the element and the document? For better or worse, existing implementations are still prefixed as far as I know and incompatible with each other. So that in itself is not really an argument for changing the standard. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Fullscreen events dispatched to elements
On Tue, Jun 5, 2012 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble jer.no...@apple.com wrote: Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Why should we standardize this if we always notify the document? Is there a benefit to notifying both the element and the document? Many applications will consider they are the only users of an interface. If so, it doesn't matter much where the notifications come in. Next, developers are likely to include more than one bit of functionality on a page. E.g. a game portal with a few games that could be clicked on to go Fullscreen and or enter Pointer Lock. It's more straight forward to place listeners on each game's relevant elements, and not expect to receive cross communication from some other portion of the page. If listeners must all live on the document than application developers must write more code to track what's going on. Oh, you received an error event? Has this component recently attempted fullscreen/lock? What if you did request and you will succeed, but another component also requested on the same user gesture and that generated an error event? Application developers all must go through some additional checks to figure out if the messages were intended for them. Finally, some pages may have applications that expect to be removed from the DOM. I don't think we'd expect this very often, but developers should be able to handle it. Even if the specs didn't dispatch change events to the document the developers could detect that the element was removed and stop whatever they were doing with them.
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 5, 2012, at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote: Why should we standardize this if we always notify the document? Is there a benefit to notifying both the element and the document? I think Vincent put forward a reasonable argument. The document is a finite, shared resource. Requiring authors to share that resource will inevitably lead to conflicts. Those (hypothetical) conflicts may be manageable, but including the fullscreen element in the event dispatch gives developers a means to avoid them entirely. For better or worse, existing implementations are still prefixed as far as I know and incompatible with each other. So that in itself is not really an argument for changing the standard. Of course. I was just pointing out an alternate solution. -Jer
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. -Jer
Re: [whatwg] Fullscreen events dispatched to elements
On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote: On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Did you inform the spec editor(s) when you decided to make this change? What did they say? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] Fullscreen events dispatched to elements
On Jun 4, 2012, at 10:43 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote: On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote: Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Actually, in WebKit, we explicitly also message the document from which the element was removed in that case. I don't see why this behavior couldn't be standardized. Did you inform the spec editor(s) when you decided to make this change? What did they say? As it is a holdover from when we implemented the Mozilla Full Screen API proposal[1], which required that behavior, no. -Jer [1] https://wiki.mozilla.org/Gecko:FullScreenAPI#fullscreenchange_event
Fullscreen events dispatched to elements
I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. The Fullscreen specification calls for events to be dispatched to the document, but the WebKit implementation dispatches fullscreenchange and fullscreenerror events to the context element (and they bubble to the document). IMHO Pointer Lock would be more convenient to use if events are sent to the target element as well, and not just the document. Is there a reason the Fullscreen specification doesn't dispatch events to the most relevant element? There is a related thread started on May 11th 2011 by Jer Noble where he proposes dispatching to the elements, but the thread moves onto other topics. I don't see a resolution regarding dispatching to elements other than early general approval by Robert O'Callahan. [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: Fullscreen events dispatched to elements
On 2/06/2012 11:19 a.m., Vincent Scheib wrote: IMHO Pointer Lock would be more convenient to use if events are sent to the target element as well, and not just the document. Is there a reason the Fullscreen specification doesn't dispatch events to the most relevant element? Because we exit fullscreen when the fullscreen element is removed from the document, so if you dispatch events to the context element, the fullscreenchange event never bubbles up to the containing document in the exit-on-remove case. Because of this, the spec was then changed to dispatch fullscreenchange to the context element on entering fullscreen, and to the document on exit, but we found this inconsistent, since a listener has to listen to multiple nodes to receive both exit and enter events, so the spec was changed again to always dispatch fullscreenchange to the document. Regards, Chris P.
