– DRAFT –
PEWG

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