Meeting minutes
ScribeNick Patrick_H_Lauke
Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445
Patrick: where are we up to? seeing some activity...
<mustaq> Reopened w3c/
Patrick: https://
<mustaq> Sent a PR to fix.
Patrick: 6 still open. do you think we can get these done, do you need extra help?
Mustaq: should be ok, going a bit slow
Olli: there will be holidays soon - will be away in July likely
Mustaq: should be able to split between us
ACTION: continue working on these
Heartbeat: Clarify what the target of the click event should be after capturing pointer events w3c/pointerevents#356
Patrick: made a changed codepen, but didn't collate all results. should i still do it?
Rob: I did testing myself, and mousedown target is always consistent with the pointerup target, even when the capture was established during pointer event which happened "first"
Olli: and even if you release in pointerup?
Rob: yes
Rob: Mustaq and I had offline discussion last week...what user may be doing, what dev expectation may be
Rob: we talked about boundary events previously, and they're not consistent with click event already at this point
Mustaq: makes sense to maintain special status of click event...
Patrick: sorry, my connection is really bad, missing every other word at the moment...
Patrick: did we get to an agreement then?
[Rob and Olli confirm]
Mustaq: compat side...
Mustaq: [is low risk?] because it's different in all browsers already anyway (?)
Mustaq: in case something still breaks, we can reconsider
Olli: we can say that this is resolved, we need a PR
Mustaq: I can take care of that
Olli: that's fine, I can review
Olli: and then there's the issue with lostpointercapture w3c/
Mustaq: second comment...
Rob: it's already agreed that the click's target is based on down and up, so don't need to ... (?)
Olli: so lostpointercapture can happen first
Mustaq: because click is a special high-level event
Olli: i'm fine with that
Olli: if you explicitly or implicitly release, it's the same
Rob: yes because the top event is captured
Olli: if pointercaputre released before pointerup, then click is not handled in any special way
Rob: conceptually calculates target at some point where we get pointerup
Olli: adding comment to #357 - fire lostpointercapture before click
Patrick: does this need change/more explicit wording in spec?
Mustaq: i think so, will try to tackle with the PR for both issues
Olli: because currently spec seems to say both behaviours are fine which is contradictory
Mustaq: question - does this thinking apply to auxclick and contextmenu etc as well?
Rob: shouldn't be differrent...
Mustaq: UI event spec doesn't mention common ancestor at all for those events
Rob: we're using the targeting based on the events that led to the click...
Rob: same idea could be applied to auxclick etc
Rob: e.g. if auxclick is result of a single event, then its targeting depends on targeting of that single event (?)
Rob: this is platform dependent
Rob: contextmenu shows up on the down, and sometimes on the up. will vary by platform, but consistent with our handling of click. when based on down event, use targeting from down event, etc
Rob: if not using common ancestor, just go by what the up event is
Olli: but auxclick is different
Mustaq: don't even know if auxclick has common ancestor concept
Olli: might be a gap/shortcoming of UI event spec, not necessarily intentional that it's not mentioned
Olli: ...there is also double-click
Mustaq: inclusive ancestor wording in UI spec is very handwavy. so think we need to add auxclick there as well
<mustaq> https://
<mustaq> auxclick should be there too, right?
<mustaq> By "there" I mean the text around "nearest common inclusive ancestor"
Rob: looks to me auxclick should use same inclusive ancestor targeting
Rob: auxclick definition says it's always a press and a release
<flackr> https://
Rob: should use same targeting behaviour as click
Olli: Firefox does it
ACTION: mustaq to draft PR to cover #356 and #357, Olli to review
TPAC
Patrick: confirming i'll be physically at TPAC
[Olli and Mustaq confirm they will also be physically there, Rob will join virtually]
Patrick: additionally, worked with Philippe for the charter extension, and said that we're roughly aiming at getting last blocking issues addressed before TPAC
Patrick: then to move forward with spec, we'll need to do the implementation report etc. Even if not fully implemented (though ideal), we need at least commitment/signals from different browser engines that they plan to implement the new parts, so shouldn't be a problem
Patrick: thank you all. As said, will send reminders well before next meeting.