- From: Mustaq Ahmed via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Mar 2016 21:07:39 +0000
- To: public-pointer-events@w3.org
>> Problem 2'. Before "blue" receives pointermove in step 22, it should receive pointerover/enter. Spec is silent again as in Problem 1, but Edge follows the spec this time. > Why do you say blue should receive pointerover/enter? Even when captured, I thought an element should get over/enter only when the cursor has crossed into the bounds of the element. You are right, I corrected my mistake after posting it, sorry. >> Problem 3. After "blue" captures the pointer (step 19), "green" shouldn't receive any event. So firing of pointerout/leave to "green" (steps 20, 21) is conceptually wrong even though the spec suggests the same order if "green" hadn't captured the mouse in step 5. Edge implementation seems to follow the spec order. > I agree that seems more logical. The implications in practice aren't clear to me though - are there scenarios that would work better or worse given this change? I don't have any concrete use-case, but in general, if a web API can avoid pitfalls, it should because there is no way to correct copied JS snippets on the web. Here is why I think Problem 3 can be called a pitfall: While got/lostpointercapture provide the ideal way to argue about "capture state" in JS, web developers (or software engineers in general) seem to rely more on _what works_ than _what is documented_. I fear that "a non-capturing element receiving events" could be taken as an equivalent to "losing capture" by developers because (i) it doesn't fit common sense, and (ii) Navid's repro is really a hidden case---that's why it went unnoticed so far. -- GitHub Notification of comment by mustaqahmed Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/39#issuecomment-193966884 using your GitHub account
Received on Tuesday, 8 March 2016 21:07:41 UTC