- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 3 Jun 2026 16:06:04 +0100
- To: public-pointer-events@w3.org
Dear all, the minutes from today's meeting can be found at https://www.w3.org/2026/06/03-pointerevents-minutes.html and copied below: PEWG 03 June 2026 Agenda: https://www.w3.org/events/meetings/bc0bed33-fd93-40a6-95bb-10f27c641863/20260603T100000/ IRC log: https://www.w3.org/2026/06/03-pointerevents-irc Attendees flackr, mustaq, Patrick_H_Lauke, plh, smaug, vmpstr Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Status of WG charter * PE Level 3 status * Broken links in Pointer Events #641 w3c/pointerevents#641 * action from last meeting Patrick to file an issue on PE about removing reliance on/reference to remaining UI events, we can flesh out further * action from last time mustaq to look at moving/removing references to UI events related to pointerlock spec * Any "MouseEvent" issues that need to be prioritised? https://github.com/w3c/pointerevents/issues?q=is%3Aissue%20state%3Aopen%20label%3AMouseEvent * TPAC # Status of WG charter plh: has been sent for review, deadline end of June. should be smooth, people will remain in the WG, purely administrative at the moment plh: as soon as we incubated an explainer for gestures, we can recharter - we won't have to wait for 2 years though plh: we can make room in this WG to incubate # PE Level 3 status plh: also under AC review, sent it after extending group charter. once we have new charter, we can forget about PE 3. i will then remove PE 2 plh: and next time we'll be more strict about PE 4 shipping ... unlike PE 3 that got stuck for a long time trying to finalise one last feature plh: thank you all for your work on the tests/test results # Broken links in Pointer Events #641 w3c/pointerevents#641 plh: this got fixed by itself when we republished PE3. can be closed patrick: done # action from last meeting Patrick to file an issue on PE about removing reliance on/reference to remaining UI events, we can flesh out further patrick: gave myself a task to file an issue. not looked in depth but specific issue is here w3c/pointerevents#644 patrick: wondering if we can firm things up a bit ... like the move of keyboard event potentially to editing WG plh: timing is unfortunate for us to do it, as it's not in charter ACTION: plh to look into talking to editing WG to take over keyboard part of UI events plh: fundamentally not a PE issue though patrick: yes, it's just that we stripped UI events for parts for what we need, so the remaining bit is keyboard so this is more a courtesy for editing WG to deal with taking over the orphaned remains # action from last time mustaq to look at moving/removing references to UI events related to pointerlock spec mustaq: didn't have time, can look at it soon plh: if you need help, let me know plh: i can make PR for pointerlock ACTION: plh to move pointerlock-related parts of UI events to pointerlock # Any "MouseEvent" issues that need to be prioritised? https://github.com/w3c/pointerevents/issues?q=is%3Aissue%20state%3Aopen%20label%3AMouseEvent patrick: happy to do it async, or we do it now plh: editorial: we need to harmonise in our spec how we present events. currently there's a mix of styles patrick: i'll look at this, report back next time ACTION: Patrick to look at harmonising how events are presented (old UI events style and our own legacy way) plh: should prioritise mouse events and pointer events in terms of initialisation flackr: one thing we were missing originally was an authoritative target. ui events was handwavy there, and we had trouble piggy-backing on that. now that we took ownership, we control the dispatch algo ACTION: flackr to look at any duplication we now have about event dispatch/initialisation mustaq: the handwavy prose about out and in events and how they're fired <mustaq> Old handwavy mouse boundary event "spec": https://w3c.github.io/pointerevents/#mouse-event-order plh: dispatch first, then initialisation. once clarified those, then we can move event by event to make sure they're consistent. and then hit testing, because it's super easy /s <flackr> https://drafts.csswg.org/css-ui/#pointer-events-control plh: do we need to look at event order? flackr: the mouse-related order is still valid, but then the question about when exactly they interleave patrick: because originally in PE we were quite handwavy about the order you MIGHT get flackr: now the dispatch should also care about pointer capture, which will be nice # TPAC patrick: when's the deadline for TPAC? plh: deadline 17 June. who's going? Patrick: I am Olli: I am (others unlikely) plh: we don't necessarily need our own meeting slot. can always ask other chairs if they want somebody from PE and we can go into their meetings Group decided not to have a specific meeting slot, but for those there happy to join other groups on request Olli: so should we go async through the existing issues in https://github.com/w3c/pointerevents/issues?q=is%3Aissue%20state%3Aopen%20label%3AMouseEvent about dispatch? plh: yes, and then move to initialisation <smaug> Tiny bit related to dispatch. https://mozilla.pettay.fi/composed-events-dispatch.html is a visualization for .relatedTarget and .composed -- Patrick H. Lauke * https://www.splintered.co.uk/ * https://github.com/patrickhlauke * https://flickr.com/photos/redux/ * https://mastodon.social/@patrick_h_lauke
Received on Wednesday, 3 June 2026 15:06:16 UTC