– DRAFT –
PEWG

<smaug> just a sec

Recharter w3c/strategy#515

<plh> Patrick: outstanding document on which types of gestures.

<plh> ... that's WIP on my part

Patrick: filed this a few minutes ago w3c/pointerevents#636

<plh> Patrick: looking at at the various available events and refining them

<plh> ... mostly Apple and Hammer.js

<plh> ... taking ideas from both

<plh> ... pan is probably not needed

<plh> flackr: we could eventually add more events, like skills. not necessary for our first iteration

plh: might be good to come up with user requirements/technical requirements to focus our effort / give us a plan

<plh> patrick: we talked about swipe, rotation, and zoom

<plh> ... we would start with swipe (multiple pointers or not?)

<plh> ... an other idea: things to do with coalesced events, ie adding references to them

<plh> ... ie finding the event streams for each individual gesture

<plh> flackr: coalesced would give a list of gesture, and you can dig further

<plh> ... mostly take the apple thing and improving will be very amenable to them

<plh> Patrick: you mentioned swipe could be detected with those 2

<plh> mustaq: from dev prospective, [...]

<plh> flackr: hammer swipe one fires continuously ?

<plh> patrick: I think it fires at the end

<plh> ... dev just want to know if the user swiped left

<plh> flackr: they'll need feedback, ie the user is swiping. so some panning, then swipe

<plh> [from higher events to the underlying ones: swipe, pan, [...], click]

<plh> Patrick_H_Lauke: you could do that today...

<plh> flackr: pinch, zoom, rotate are difficult

<plh> Patrick_H_Lauke: yes, 2 or more fingers

<plh> mustaq: higher level events are more dev friendly

<plh> Patrick_H_Lauke: don't know if there is a react module for this

<mustaq> One data point for us could be: how popular the hammer.js model is.

<plh> plh: we should also look at other platforms (android, ios, etc.)

<plh> flackr: chrome was built on android events

<Patrick_H_Lauke> flackr: having single event may be easier, rather than different events for different types/discrete events

Patrick_H_Lauke: depends on use cases, dev will want different level of events

philippe: we need use cases and requirements

<Patrick_H_Lauke> plh: there is a w3c breakout day end of march. we could organise a breakout to get feedback / get requirements

w3c/breakouts-day-2026

deadline for proposals is 10 March

<mustaq> My quick read of Android doc suggests their model sits between Apple's and Hammer.js's: onScaleBegin...onScale...onScaleEnd

<mustaq> https://developer.android.com/reference/android/view/ScaleGestureDetector.OnScaleGestureListener

ACTION: patrick to create an issue in PE repo about breakout session. group to start thinking about use cases, approaches, etc

Follow-up from UI Events meeting https://docs.google.com/document/d/1iRFgqtReyomoCwZFEdRUdoW1ManD5t656CVUGJm7Xos/

<Patrick_H_Lauke> plh: not done addressing all feedback from 2 weeks ago, but working through. DOMActivate there's now issue in HTML specification. need to still add warnings in sections.

<Patrick_H_Lauke> plh: talked to francois about all the dependencies

<Patrick_H_Lauke> plh: short story, not done, should be done in 2 weeks / will try, so potentially before next UI events call we have things ready to merge after that

<Patrick_H_Lauke> plh: will have to have a separate deeper discussion about default action. only pointing to the definition for now, but will want to tackle it more fundamentally

WPTs

https://w3c.github.io/pointereventswg/implementation-reports/wpt-pointerevents-2026-01-25.html

<Patrick_H_Lauke> plh: i generated the wpt report for what i think is the relevant list of tests for v3

<Patrick_H_Lauke> plh: plenty of fails, but overall seems "ok"

<Patrick_H_Lauke> plh: cases where we don't have 2 implementations, but mostly seems down to bugs rather than anything else

<Patrick_H_Lauke> plh: if group is ok with it, i'd like to ask for PE v3 to go through. deprecate v2 and tell people to use v3. then we can forget about v3

<Patrick_H_Lauke> plh: we happy to say the results are good enough? or we want to wait?

<Patrick_H_Lauke> olli: worth mentioning as well that some fails MAY be down to test harness

<Patrick_H_Lauke> plh: would be good to identify which ones. i think the one related to keys (alt/control/meta/shift). lot of failures there

<Patrick_H_Lauke> plh: lot of missing test results, i'm guessing it's down to harness

<Patrick_H_Lauke> plh: all of the offset-x / offset-y, guess it's because we don't use them in pointer events

<Patrick_H_Lauke> plh: in any case, i believe this is good enough.

<Patrick_H_Lauke> plh: do you want more time to look at the results, to see if you want to improve them?

<Patrick_H_Lauke> plh: we don't need perfection, just demonstrating there's nothing wrong with the spec

<Patrick_H_Lauke> mustaq: will take a look at some more failures...

<Patrick_H_Lauke> plh: up to the group to decide

<Patrick_H_Lauke> olli: realistically, we're probably not going to fundamentally fix many more in the next 2 weeks or so. also, next interop coming up, so we could change them further

<Patrick_H_Lauke> mustaq: we can say we'll cover some of these in interop 2026

<Patrick_H_Lauke> Patrick: let's give it another 2 weeks, then at next meeting have a go/no go decision

<smaug> Ok, in Firefox many of the pen tests are ""Error: action_sequence() is not implemented by testdriver-vendor.js""

<Patrick_H_Lauke> plh: and i can easily regenerate report, automatically updates

ACTION: for next meeting, review WPT test results

<smaug> mustaq: pointerevent_pointerrawupdate_coalesced_events_attributes.https.html?touch is also surprising