Meeting minutes
wide review
Patrick: w3c/
Patrick: been slack after TPAC with vacation and another conference, but am now looking at this
Patrick: extra wrinkle is our charter runs out, so coordinating with PLH about extending it again
Patrick: want to get this done on my end ASAP
Rob as co-editor
Patrick: you may have seen, but now Rob officially co-editor as well
wide review and charter
plh: timeline in charter is outdated, so don't know what to put
Patrick: if I kick off wide review now, how long will it take realistically?
plh: usually 2 months, maybe even 1
Patrick: safer to say 2 months
plh: when do you expect wide review to be sent out?
Patrick: want to get it done tonight, tomorrow, this week at least
plh: so that puts us into January. i'll update timeline and charter
Review outstanding v3-blocker issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking
Patrick: where are we up to with #477 w3c/
mustaq: we have comment that we need one implementer. chrome will hopefully have this. also we need a WPT for shadow DOM
Olli: yes we need to define how that is supposed to work
mustaq: anyone working on that WPT?
Olli: i'm not on that one, no
<mustaq> I am not either!
Olli: hoping that while writing the test, it will become clear what the right approach should be
Olli: it should be event path though, as mentioned
Rob: yes, it's mentioned in various places, like UI Events, but they don't mention shadow DOM
Olli: was thinking DOM spec, if there's a nice algorithm...
Rob: we need to define event path somewhere, and then refer to it. then we can just refer to parent in event path
Rob: the modification ... you need to do this not while processing the event, happens outside of the event processing. you could refer to the historical event, but realistically want to follow same logic as an event that would have targeted that element
mustaq: the event path is constructed during the dispatch, so will be tricky...
Rob: we should use same rules as the constructed event path for the thing that you're now considered to be over
Rob: i see you (Olli) have added a link to the DOM spec event path
Olli: yeah but sorry if we can't really use any of the algo. because it's to dispatch an event to a target. then there's the composed (?) path
Patrick: so we still iterating...
Rob: looks like the event dispatching constructs the path, so maybe can extract that
<smaug> https://
<flackr> https://
Patrick: are we defining stuff that we shouldn't?
Rob: I want to take 5.9 and just extract/reuse that
Rob: you keep stepping up until you get to the root, and that's what defines the path
mustaq: so we basically say ... "conform to 5.9" so we don't need to change the DOM spec
Rob: that would be the correct test, but we probably need to say something more direct in our spec. when target is removed, we follow this algo until we find a still attached node
Patrick: just wondering, as this is the last substantive change, should we hold off with wide review until we have this?
Olli: yeah, might be true
<mustaq> w3c/
Patrick: we can probably go for review before there's implementation and WPT, but we probably should make the change to spec first before asking for review
mustaq: filed the above bug which is related...
Rob: I thought our spec did say what to do
Olli: yeah so did i
mustaq: feel free to comment in issue, maybe i missed something
Rob: section 9.5 implicit release of pointer capture says that when target override is no longer connected, we clear ...
Olli: need to look whether it's talking about connected, disconnected, or removed
mustaq: ... we're expected to fire lostpointercapture...
Rob: I believe so
Olli: this is the behaviour that browsers had
Rob: I thought so yes
mustaq: the timing is not clear. the get or lostpointercapture is fired in a lazy manner
<Patrick_H_Lauke> s/manger/manner
mustaq: should we fire immediately after DOM change or should it wait?
Rob: it also talks about the pending pointer capture in 9.5. my reading is that it should be immediate
mustaq: i think second para mostly addresses that, but timing could do with clarification
Rob: we don't want to fire immediately as that makes it sync, but we should treat it as lost pointer capture as normal and queue it
Olli: do we queue a task or run as soon as possible
mustaq: lazy mechanism might not see it as a change that needs dispatching
Rob: when does the pending stuff get sent
Rob: ... do we expect a notification when we don't get pointercapture?
mustaq: lazy mechanism mentions something...
<mustaq> https://
mustaq: i think this section (link) mentions the lazy mechanism
Rob: right now, i f you set pointercapture, if you remove node before the next event, there will be no notification that you didn't succeed in getting pointercapture
mustaq: which is fine right?
Rob: not great from a developer perspective
mustaq: it's not a got or lost, it's a cancel pending request
Rob: you could send lostpointercapture, but then it wouldn't match up to a gotpointercapture
Rob: maybe it's something we add in future...
mustaq: back to timing, do we agree...
Rob: it says "otherwise clear the pointercapture target override". is that when we fire lostpointecapture.... oh no it's step 1
Rob: if the node was removed, it would be in step 1 that we detect that the capture target is null
Rob: that's the point where we would fire lostpointercapture
mustaq: so there we should immediately set pending to null
mustaq: please comment in issue, then we can resolve this easily
ACTION: review #487 and hopefully close if already covered
Patrick: getting back to #477 who would like to take a stab at this
PAtrick: would be keen to get the small change in our spec
Rob: not sure how easy it is to get change into DOM spec...
Patrick: but just the part for our spec...
Rob: I can try and just reference...
ACTION: Rob to review/make necessary change to PE spec relating to #477
interop 2024 effort
mustaq: want to highlight proposal for pointervent/mouseevent
<mustaq> Interop 2024 carryover proposal for Pointer Events and Mouse Events:
<mustaq> web-platform-tests/
<mustaq> It would be great to see other browsers adding to the list.
Patrick: so is this for Olli to be aware of and have a look at? Yeah, cool
ACTION: Olli to review interop 2024 carryover proposal for PE and Mouse Events
sideline pointervent id
Patrick: https://
Patrick: assume this is stuff for future versions of PE?
Rob: yeah that seems reasonable
Patrick: not trying to put any of you on the spot, just wondered if you had more inside knowledge
Patrick: assume this is what came out of the presentation we had a while ago from... Microsoft? Wacom? ... about their idea to store id more permanently to then open up possibility of storing preferences
Rob: looks like that on that intent thread two of the owners pointed out it should have a spec
Patrick: cool, just no action right now, just something to be aware of that it might come in for future versions
Rob: FWIW i reviewed early work on this, and made sure things were designed in similar way to what we already have. but yes we'll evaluate it properly when it comes to us