[w3c/pointerlock] Dispatch pointerlockchange and pointerlockerror events to target element, falling back to document. (#21)

Pointer Lock intentionally follows the Fullscreen specification patterns. That spec is adopting an event dispatch behavior from the WebKit implementation. https://github.com/whatwg/fullscreen/issues/89

I'm copy pasting the fullscreen text. Logically for pointer lock this will apply to `pointerlockchange` and `pointerlockerror` events.

mounirlamouri wrote:
>
> At the moment, my understanding is that fullscreenchange fires on the document while webkitfullscreenchange fires on the element that enters/exits fullscreen and bubbles up to the document.
> 
> I see the following reasons to keep the webkitfullscreenchange behaviour:
> 
> * compatibility: likely, some websites that try to assume a non-prefix API will exist add the event listener to the element and simply change the event name. I definitively tried to do that once until @foolip told me I'm wrong;
> * simplicity/less error prone: it will increase the chances of developers to trigger behaviour change when a specific element goes fullscreen instead of anything inside the document (ie. it is easy to not check which element is fullscreen when the document becomes fullscreen).
>
> The only reason I see to fire the event on the document is for the API to be wrapped around the Document interface instead of being spread around multiple interfaces but it's already the case with enterFullscreen() so maybe that battle is already lost?
> 

The compatibility argument doesn't apply, but the simplicity does. Consistency between pointer lock and fullscreen is the most compelling.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/issues/21