- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 9 Sep 2026 16:08:06 +0100
- To: public-pointer-events@w3.org
Dear all, the minutes from today's meeting are at https://www.w3.org/2026/09/09-pointerevents-minutes.html and copied below: PEWG 09 September 2026 Agenda: https://www.w3.org/events/meetings/bc0bed33-fd93-40a6-95bb-10f27c641863/20260909T100000/ IRC log: https://www.w3.org/2026/09/09-pointerevents-irc Attendees flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Reviewing areas in the (now merged) spec that have warnings/notes applied to them * dblclick specified to be fired as PointerEvent w3c/pointerevents#650 * aob # Reviewing areas in the (now merged) spec that have warnings/notes applied to them Patrick: from last time, i now merged the work we were doing in the separate branch into main Patrick: so now that it's "live" on https://w3c.github.io/pointerevents/ probably worth having an initial look at all the sections that are marked with warning boxes to see what we should focus on/rewrite Patrick: https://w3c.github.io/pointerevents/#pointerevent-algorithms we have some TODO items / editor's notes mustaq: these "maybe send..." sections are part of event dispatch? mustaq: these sections were all tentative / initial roughs mustaq: this is just setting the target and sending the event. isn't it implicit? do we need explicit sections for that? Patrick: "definitely maybe" https://en.wikipedia.org/wiki/Definitely_Maybe mustaq: the caller algorithms that Olli pointed out have some value (they link back to these), but otherwise we can probably remove these sections altogether smaug: we can probably remove all the "maybe"s since this is now all contained in our own spec smaug: we do need to keep the 11.2... mouse events algorithms <mustaq> I propose dropping 3.2.4 ~ 3.2.11 as they ass no value (and creates conflict with 10.1 e.g) mustaq: the "maybe"s seem to suggest what the sequence of mouse and then pointer is, but this is not fully correct as we already point out in section 10 that there can be scenarios where you have multiple mouse events as a result of pointer Patrick: as initial attack point, should I file an issue (and small PR with it) to remove all the "maybe"s [discussion on wheter we even need 3.2.1 / 3.2.2 / 3.2.3] Olli: we do need something algorithmic to say how to deal with event target etc mustaq: if you look at our new boxes, like 3.3.1, in "Context" we say something about relatedTarget ACTION: Patrick to file an issue about high-level "Deal with section 3.2 as it's currently contradictory with other parts of the spec, while also having very low value" Patrick: and then from11.2.x onwards we have the big warning boxes mustaq: we discussed this back at TPAC a few years ago already... mustaq: at the native level, touch doesn't generate mouse events, so we need to explain somehow at high level what needs to happen (e.g. that a mouse event needs to be fired, and also a pointer event) mustaq: "native pointer event", "native mouse event" Patrick: maybe using some high-level folksy language (rather than inventing new terminology), like "if the user input came from a touchscreen interaction, generate a MouseEvent and a PointerEvent" type thing mustaq: algos in section 11 provide the entry level, but then point back to algos in 3.2 / maybe. so suggest we remove 3.2, and work on clarifying things in 11 Patrick: possibly also think about renaming the section. currently 11 appears to be just about mouse, and lives in the mouse part of the spec. need to make clearer it's about general "Event handling and interfaces" or similar rather than purely "MouseEvents and interfaces" <mustaq> Another observation: sections 11.2.8 and 11.2.9 seem redundant/implied. ACTION: Patrick file another high-level issue on "Rework section 11"... # dblclick specified to be fired as PointerEvent w3c/pointerevents#650 Patrick: so this issue points out that https://w3c.github.io/pointerevents/#handle-native-mouse-double-click indicates the dblclick is a pointer event, which is not correct since we clearly state in https://w3c.github.io/pointerevents/#dblclick that it's a mouse event # aob <smaug> w3c/uievents#413 Patrick: just a note that after merging the branch into main, i spent some time making sure to resolve merge conflicts on https://github.com/w3c/pointerevents/pulls. now that we published 3 and are working on 4, we should consider what we want to do with these hanging PRs. can maybe merge them tentatively then refine once they're in the draft Patrick: so i think overall, our priorities are to get our draft in a clearer shape now post merging of UI events, in particular making sure the algorithms aren't contradictory and actually reflect reality/what should happen. and clearing the hanging PRs after that. THEN, we can look at the nearly 100 issues we still have on the repo Patrick: many of the inherited ones labelled MouseEvent etc may well be resolved after work on algo section has been done, but let's start first with doing best effort to rejig algos first, then see what's missing/outstanding Patrick: thank you all, and we'll catch up again in 2 weeks' time Summary of action items * Patrick to file an issue about high-level "Deal with section 3.2 as it's currently contradictory with other parts of the spec, while also having very low value" * Patrick file another high-level issue on "Rework section 11"... -- 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, 9 September 2026 15:08:13 UTC