Meeting minutes
Clarify mousedown event target if the preceding pointerdown event listener removes the target #492 w3c/pointerevents#492 - this has an associated PR w3c/pointerevents#494
Olli: regarding the comment https://
Mustaq: w3c/
Mustaq: right after second note
Mustaq: "Unless otherwise noted, the target of any mapped mouse event SHOULD be the same target as the respective pointer event unless the target is no longer participating in its ownerDocument's tree."
Mustaq: point 2 is covered by the last "Otherwise" in the PR https://
Mustaq: point 3 of Rob's is tricky. asked for remembering the target...
Rob: this is what you get by default
Mustaq: the last point in my PR should cover this
Rob: shouldn't need to have any check whether they're connected...I suppose you could find the common ancestor of td and tu
Rob: if that common ancestor is connected, then both td and tu must be connected. simpler perhaps?
Rob: if either td or tu are disconnected, they won't have a common ancestor. if both are disconnected, they may have a common ancestor that is also disconnected....
Mustaq: just want to make sure that we hone in on the DOM "at the current moment"
Rob: is this moment the moment of the pointerup dispatch or is it...
Mustaq: what happens if pointerup also modifies the DOM ...
Mustaq: moment of click dispatch
Rob: think it's ok, but it's important
Mustaq: we could land it and then add a second pass...
Rob: we could land this and test it, think it's ok to say at the moment of click dispatch
Rob: no expectation that click goes to the same element as the up
Mustaq: looking at the WPT we made for this ...
Rob: did also want it so that if the up had been captured, the click is also captured, right?
Rob: don't know if we did this yet, but i remember we discussed this to make it simpler for developers
Mustaq: my third point i think captures this
Rob: what i'm getting at is that that is computed at the pointerup, and that may be a good reason to keep this at the moment of pointerup dispatch (?)
Rob: probably simpler - if we're doing some calculation of click target at pointerup, then maybe we should also be calculating at the moment of pointerup dispatch
Rob: if pointerup modifies DOM so that nearest common ancestor is different, you won't see it in the click event
Mustaq: in my PR, point 4 about auxclick is affected by capturing, but not by common ancestor...
Mustaq: maybe we can shuffle points 3, 4, 5 to be simpler
Mustaq: let's look at PR again, if you spot a better/clearer way
Rob: common use case is either down or up event reorders the DOM (e.g. brings things on top by being the last in the DOM). still want click to be dispatched to the right thing. maybe that's not affected by when you compute target
Olli: in gecko, we store click target before dispatching up
Rob: which is consistent with how we want it to work
Olli: and looks like it's been done on purpose
Rob: that also makes capture case make much more sense
Rob: because after firing the up you lose capture
Mustaq: someone please write it down
Rob: click target is determined before dispatching the up
Mustaq: talking about WPTs
<mustaq> WPTs that cover this PR already are: pointerevents/pointerevent_after_target_{appended,removed}.html
<mustaq> except for the captured case, which I guess is covered elsewhere.
<mustaq> Perhaps this covers the last case: pointerevents/pointerevent_click_during_capture.html
Mustaq: i'll try to rewrite it this/next week. WPT coverage not clear, maybe we have cover for this one including target
ACTION: Mustaq to iterate over https://
Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445
Patrick: I think we're left with these at the moment https://
Olli: I have reserved time for some of these
Rob: left a comment on PR 494 about what i think needs changing
brief discussion on PR about pointerEvent spec addition of deviceId
Olli: concern that this competes with the idea we saw from Intel from a few months ago
https://
Rob: Microsoft's new proposal is super-narrow - you only get the id until hardware can determine it / on pointerdown in most cases
<mustaq> There is another similar issue: w3c/
Patrick: worth keeping an eye on this, but no immediate action until we get PE3 out the door. We'll reconvene in 2 weeks' time, thank you all