- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 11 Feb 2026 15:50:13 +0000
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2026/02/11-pointerevents-minutes.html and copied below: PEWG 11 February 2026 Agenda: https://www.w3.org/events/meetings/bc0bed33-fd93-40a6-95bb-10f27c641863/20260211T100000/ IRC log: https://www.w3.org/2026/02/11-pointerevents-irc Attendees dbaron, flackr, mustaq, nicolo-ribaudo, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Recharter w3c/strategy#515 * Follow-up from UI Events meeting https://docs.google.com/document/d/1iRFgqtReyomoCwZFEdRUdoW1ManD5t656CVUGJm7Xos/ * WPTs * Changing target of click events (in some cases) # Recharter w3c/strategy#515 Patrick: Philippe noted on the issue that we're refining this some more until April. we're going to be running a breakout session to get people's ideas. lots of folks already commented on the issue we filed about gesture support Patrick: I'm on the hook to write a few thoughts / put together a few slides for the breakout session. need to submit by around 10 March. for next meeting i'll have something together for us to discuss, just to give context to folks, why we're doing this, what we're considering at the moment ACTION: draft breakout session ideas/slides to sell the idea to folks to attend # Follow-up from UI Events meeting https://docs.google.com/document/d/1iRFgqtReyomoCwZFEdRUdoW1ManD5t656CVUGJm7Xos/ Review https: //github.com/w3c/pointerevents/pull/564 / w3c/uievents#411 Rob: I've been through the PR, looks good Olli: ditto plh: did not copy over entire acknowledgement section, but kept a small selection plh: i fixed referencing of the pointer event handlers. but we have a definition for cancelled event - we say in the algorithm that if the cancelled flag is set... so i simplified this and removed the definition itself, simplifying things plh: right order is to merge PE first, then UI events afterwards once the PE spec has been regenerated. so at this point, can i merge? Patrick: group agrees. thank you Philippe # WPTs Patrick: space to discuss problems/concerns about WPTs <plh> https://w3c.github.io/pointereventswg/implementation-reports/wpt-pointerevents-2026-01-25.html Philippe: asked last time if we're happy to move the WPTs. you asked for more time to review/make sure this won't cause problems Philippe: this (link above) is the report i pointed you to last time Olli: yes need to take a look at that some more... Philippe: we'll come back to this in two weeks. I can regenerate the report, but will then need to remove mouse/wheel ACTION: group to review implementation report # Changing target of click events (in some cases) <dbaron> w3c/pointerevents#637 David: discussion in openUI CG - relates to customisable select (already shipped in chrome) and menu elements David: small issue in select, but bigger problem in menus David: both of these have interaction pattern where you mouse down in one place, it opens something, then mouse up somewhere else and it's an activation David: worried about developers writing content that handles click event for those ... they'll work in SOME cases, but won't work for other ways - click,click,click versus mouse down/move/mouse up David: what openUI proposes is click events will go to the right place by default. wrote the above PR to allow this. this would provide a hook in PE that can then be referenced David: certain elements "capture" (not good term) click event. click doesn't go to nearest common ancestor, but the element that's between the up event and the common ancestor. PR tweaks algo to say that sometimes there's elements in the path to the common ancestor that can grab the click event and retarget to this Rob: not sure it's the right approach, seems a bit odd. might be better to look at defining elements that act as *composite* components. not sure the proposed algo change makes sense as such Olli: was going to say same. i believe chromium had something similar to this, for a while. it was causing compat issues - override for click target. firefox copied this, but then removed it and chromium did as well Olli: capturing on the up might work? David: in the select case, anything that opens something on the down, it makes sense to fire/activate on the up (?) David: complicated by fact that there might not be a tree structure between the select/menu parent element and the active elements inside <mustaq> https://w3c.github.io/pointerevents/#event-dispatch Step 3 <smaug> yeah, capture could work at least for some cases ACTION: group to review / add feedback to PR 637 Patrick: noting that the behaviour doesn't seem to be "usual" in Windows. Might be a macOS/Linux thing? Rob: is there a chance to revisit the decision on openUI to not test/structure? David: would make things more complicated (?) David: there are situations where we can't just use interest invokers Olli: is the accessibility concern documented anywhere? Patrick: I understand that the concern about not having nested interactive controls. IF the idea is that everything is self-contained in a single element/component, I can see how for a dropdown/select where the options/items are direct children of the outer "button" that activates them would then lead to nested buttons. but looking at things like ARIA practices, that's exactly why the structure is necessarily more complex[CUT] er around the thing, and interactive control to open, and then a separate (non-child) set of options/menu items. Patrick: I'd suggest that before we look at this proposed PR, we maybe have a discussion upstream with OpenUI about this. while i understand it would make things "nice" and "clean" to keep things encapsulated, if this means breaking the event model specifically for this it may not be the best approach Rob: yes, this feels like it would set a weird precedent Patrick: thank you all, we'll catch up again in two weeks' time # Summary of action items * draft breakout session ideas/slides to sell the idea to folks to attend * group to review implementation report * group to review / add feedback to PR 637 -- 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, 11 February 2026 15:50:36 UTC