- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 25 Oct 2023 16:53:26 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's PEWG meeting are available at https://www.w3.org/2023/10/25-pointerevents-minutes.html and copied below: PEWG 25 October 2023 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20231025T110000/ IRC log: https://www.w3.org/2023/10/25-pointerevents-irc Attendees flackr, mustaq, Patrick_H_Lauke, plh, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * wide review * Rob as co-editor * wide review and charter * Review outstanding v3-blocker issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking * interop 2024 effort * sideline pointervent id # wide review Patrick: w3c/pointerevents#482 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 w3c/pointerevents#488 # 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/pointerevents#477 ? 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://dom.spec.whatwg.org/#dispatching-events <flackr> https://dom.spec.whatwg.org/#dispatching-events 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/pointerevents#487 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 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://w3c.github.io/pointerevents/#process-pending-pointer-capture 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/interop#472 <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://groups.google.com/a/chromium.org/g/blink-dev/c/3eU-AHH8x4k/m/rCyxcYnQAgAJ intent to ship in chrome 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 Summary of action items * review #487 and hopefully close if already covered * Rob to review/make necessary change to PE spec relating to #477 * Olli to review interop 2024 carryover proposal for PE and Mouse Events -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 25 October 2023 15:53:36 UTC