- From: Navid Zolghadr via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Feb 2017 20:45:34 +0000
- To: public-pointer-events@w3.org
I was playing with different scenarios and interactions of these APIs. Particularly the fact that `requestPointerLock` is an async API and it is not in effect until user accepts that. I found that defining the interaction based on which call was first seems more confusing. Note that `requestPointerLock` is a more specific API (as it is only for mouse). I would say something that is more specific should generally take precedence over something that is more generic. So how about pointer lock state always takes priority over the capture. So calling `requestPointerLock` doesn't do anything. But as soon as pointerlock is in effect if there is any capture going on (including the element that will get the pointerlock) the element should receive the `lostpointercapture`. Essentially, `lostpointercapture` should be fired before `pointerlockchange` if needed. While pointer lock is in effect `setPointerCapture` API should always fail. Since we don't have any generic exception, I wonder just silently not doing anything is fine or not similar to step 3 in "Setting Pointer Capture" section. WDYT? -- GitHub Notification of comment by NavidZ Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/176#issuecomment-279516594 using your GitHub account
Received on Monday, 13 February 2017 20:45:40 UTC