Meeting minutes
Patrick: since TPAC been swamped with work, apologies. need to still get wide review requested w3c/
Review outstanding v3-blocker issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking
Olli: just working out tests for secure context - need to rename tests for https, and not expose the http ones w3c/
Mustaq: expecting chrome will fix things very soon
Mustaq: hoping to have something in Chrome in a week
Patrick: apologies, above link should have been w3c/
Rob: when I reviewed specs, i didn't see anything relating to DOM removal
Rob: UI Events spec for 477
Rob: they gloss over the fact that DOM can change
Rob: remember reading in one of the specs somewhere that you're not supposed to fire events on removed elements
Olli: UI Events does say something ... "if the element is removed ... mouse events should not be fired to that element"
Olli: ... and Safari fires on THAT element
Rob: we're proposing for boundary events treating the ancestor of that element to be the target
Mustaq: Olli mentioned something about shadow DOM / boundary
Olli: for this issue it's not the parent, it's the same path used for event dispatching (for #477). need to use same mechanism as DOM spec
Mustaq: still need WPT for 477?
Rob: yes, to catch that case. slotted DOM element, when that's removed/changes slot...
Olli: then there's case if you're in topmost element in shadow DOM, your parent is shadow root, I think we should then skip shadow root and go to the host
Rob: intent is that this should follow the event bubbling/propagation path
Olli: we treat it that mouse is now over that parent, but it's never over the root itself. maybe it works....unusual case
Rob: there's edge cases to test, but answer may be simple. whatever element you entered to enter this sub element, that thing is the thing that should be considered over
Olli: and yes for shadow DOM, there's the root in between. may need to handle this somehow
Olli: let's say you have shadow root, and you add just one element. now move mouse over to that element, and while dispatching, you remove that element. but the parent is shadow root, but it's not an element
Rob: "parent" is too naive to say....
Olli: "nearest shadow-inclusive ancestor element"
Mustaq: maybe should just dump this into the issue (#477)
Rob: UI Events has concept of event propagation path defined
Olli: DOM spec has it
Rob: UI Events also mentions it
Olli: ..."shadow including inclusive ancestor..."
Olli: added comment to the issue
Patrick: https://
Mustaq: I was looking at #356 but can't promise when this will happen
Patrick: I would suggest if you at some point commented on any of these and said you'd do it, but then didn't get around to it, maybe comment.
Mustaq: we should assign people / self assign. just assigned something to Olli...
Mustaq: out of 7 we have 2 assigned right now
Patrick: and as ever, if you have somebody within your org that might have time/be suited, maybe ask them
Patrick: I will also label these as v3
Patrick: so yes, would be good to get all WPTs in place before we get to final stage
Rob: UI Events spec does not mention anything about shadow DOM
Olli: yes, UI Events spec is more like DOM 3 and doesn't touch shadow
Mustaq: I think there's a separate branch to make UI Events algorithmic, but a big task
Rob: the one ask would be to change the vague "ancestor" with "shadow-inclusive ancestor..."
Olli: also talks about bubbling when it should really say propagation
Rob: i'd rather WE said "follows the event propagation path" and leave it up to other spec to then define it properly
Olli: do we have something useful in DOM spec? "an event has an associated path", maybe the closest
<smaug> https://
Patrick: so after we found relevant spec, we do still need to make change to OUR spec, right?
Rob: yes, the thing we changed (about event propagation)
Mustaq: trying to find something about pointer capture and what happens there when the capturing element is removed. goes back to the document?
<mustaq> https://
Rob: we have implicit pointer capture to be similar to touch events, but TE does send events back to removed element. tested this recently. if we changed our pointer capture to be lost on element removal, that would be in contrast with behaviour that implicit pointer capture was meant to take care of
Rob: it is called out though in https://
"When the pointer capture target override is no longer connected [DOM], the pending pointer capture target override and pointer capture target override nodes SHOULD be cleared and also a PointerEvent named lostpointercapture corresponding to the captured pointer SHOULD be fired at the document."
Rob: lostpointercapture is fired, but NOT the events. it just goes through the normal event path once capture lost
Rob: we need more tests....
Olli: looks like we (in mozilla) fire to the document
Rob: but that's only for lostpointercapture
Rob: i'll file an issue about this not matching touch events, or whether we want to be different
<mustaq> We have this WPT: wpt/pointerevents/pointerevent_lostpointercapture_for_disconnected_node.html
Mustaq: we have test for lostpointercapture?
<mustaq> https://
Mustaq: we have 4 different tests for different types of nodes / shadow DOM / etc
Olli: not testing what happens to pointer events after, though. just lostpointercpature
Rob: i just wrote up #486 just to capture initial thoughts, can add more detail
Rob: ... i think that demo linked from 486 shows explicitly that PE doesn't match TE for events being sent or not to removed node
Olli: maybe that's fine, if it's been spec'd that way...
Mustaq: corner case
Rob: tested in Chrome, and doesn't fire events anymore to removed elements
ACTION: for next meeting, investigate #486 further
editor/co-editor
Patrick: as discussed at TPAC, I moved Navid to former editors. However, happy for somebody else to be co-editor, as some of the more technical aspects we're wading into are beyond me
Rob: would be good to have a co-editor, yes. I can do it
Patrick: any objections?
[group agrees]
ACTION: make Rob co-editor for the spec
Olli: (going back to 486) browsers all seem to be inconsistent, from quick testing now
Olli: testing the implicit capture....
wide review
Patrick: as said, i've been slack with getting the wide review requests out, but will definitely have this done for next meeting. and liaise with PLH on potential need for further charter extension
ACTION: Patrick to action w3c/