– DRAFT –
PEWG

Clarify mousedown event target if the preceding pointerdown event listener removes the target w3c/pointerevents#492

rob: this still needs tests, and will likely need spec changes, but we've not determined which

mustaq: we had a test, but it may need further tweaking (need to check what the click target is)

rob: there's multiple things that need to be tested about this

mustaq: yes, at one point we were missing the click target, just checking if that's still the case

rob: not just click target on removal, but if you remove and re-add, it could be the node itself

<mustaq> https://wpt.fyi/results/pointerevents?label=experimental&label=master&aligned&q=interleaved.tentative.html

mustaq: i think these are the tests, and they include re-adding. not sure if we are testing re-adding... the appended test includes re-adding. does it include click target?

mustaq: if you look at line 117, it tests click target

mustaq: i think WPT wise we are fine. do we need any spec change?

rob: probably. don't think this is spelled out

mustaq: looking at your summary (w3c/pointerevents#492 (comment)) i think point 1 is covered

mustaq: 2 needs some work (UI Events doesn't mention pointer events)

rob: 3 is default state unless you have special handling, but wouldn't hurt to have a note. doesn't need normative change

patrick: do we know what we want, broadly, for points 2 and 3?

mustaq: tricky because we're talking about click target in UI Events spec, not PE spec. do we move to PE spec?

rob: similar to our mention of compatibility events, which is basically an amendment of UI Events spec...

mustaq: the "common ancestor" term only appears in UI Events...

rob: and it's handwaved there

rob: think it's reasonable for PE spec to say the target of click events is determined by the target of the pointer events

mustaq: "common ancestor" is only mentioned in UI events spec. should UI events spec link back to PE spec?

rob: i guess, even that link may not be necessary. PE spec can have a section specifically overriding/respecifying behaviour. common ancestor determined from pointerdown and pointerup events when using PE spec. then say usually this will be the same as UI events spec ... unless it's removed ...

Patrick: i'd be careful linking from UI events to PE for something as generic as "common inclusive ancestor"

mustaq: but want to make sure that if somebody looks at UI events, they don't overlook this wrinkle

rob: if you feel a non-normative note would be helpful

mustaq: i can give it a try

ACTION: Mustaq to work on changes to PE spec to cover points 2 and 3 of Rob's latest summary w3c/pointerevents#492 (comment)

Clarify pointerleave and pointerout events when first pointer move after removing an element under the pointer w3c/pointerevents#477

Patrick: wondering generally what we need to do here

Rob: we landed spec change that explains the rough model...

Mustaq: we still need a WPT for shadow dom

Patrick: closing the issue then, added a comment about needing WPT

<mustaq> Chrome supports this behavior now as an experimental web platform feature, so we now have one impl technically.

Mustaq: let me add a comment about Chrome support

Implicit release of pointer capture on DOM removal doesn't match touch-events w3c/pointerevents#486

Mustaq: does TE spec mention DOM changes at all

Patrick: I think TE spec is very handwavy

Rob: I thought we agreed that it's ok for PE and TE to diverge

Mustaq: sure, just wanted to check

https://w3c.github.io/touch-events/

[confirming that the spec has no specifics]

<flackr> https://w3c.github.io/touch-events/#event-touchend

Rob: in touchend and touchmove it says the target must be the same target as when screen was first touched

Rob: that's all it has to say, doesn't mention DOM changes etc

Rob: ... in my view the whole area is under-specified

<flackr> Note in mouse event order implies this https://w3c.github.io/uievents/#events-mouseevent-event-order

<flackr> "If the event target (e.g. the target element) is removed from the DOM during the mouse events sequence, the remaining events of the sequence MUST NOT be fired on that element."

<mustaq> https://dom.spec.whatwg.org/#ref-for-dom-eventtarget-dispatchevent%E2%91%A2

[looking further into specs]

Rob: but for this issue, i think it's ok to accept that because TE is so underspec'd, it's ok for PE to have different target compared to TE, since browsers can't seem to agree on the target for TE's anyway (when nodes get removed)

Rob: should probably also open a new issue for boundary events (in the UI Events spec ?)

Mustaq: safe to say we can close issue, or remove WPT?

Rob: i think we're good on this issue...

Rob: we have a test for the PE side, so we're good

Patrick: ok ... closing then?

[all agree]

Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445

<mustaq> https://github.com/w3c/pointerevents/issues?q=label%3Aneeds-wpt

https://github.com/w3c/pointerevents/pulls?q=label%3Aneeds-wpt+

w3c/pointerevents#356

Rob: w3c/pointerevents#490 i added a test, removing label

ACTION: continue reviewing which PRs/issues need WPT

Patrick: thank you all, we'll reconvene in 2 weeks' time