- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 3 Dec 2025 15:24:47 +0000
- To: public-pointer-events@w3.org
Dear all, apologies, only just realised that I hadn't posted the minutes (and since RRSAgent refused to turn up in the channel, for some reason, these are purely a manual dump straight from IRC): PEWG 14 November Agenda: https://www.w3.org/events/meetings/19833134-cd0a-426a-8c78-a086c27c7a29/ Attendees: Patrick_H_Lauke, smaug, various observers Chair: Patrick H. Lauke Scribe: Patrick H. Lauke Patrick: quick intro, group has been operating for a few years. last stable spec is PE Level 2. we've been focusing on PE Level 3. the spec has been submitted for REC track, we're currently working on making sure WPTs are in order Patrick_H_Lauke Patrick: we're on a charter extension at the moment https://www.w3.org/2023/11/wg-pointer-events-charter.html ananya has joined (~ananya@6b13c2d6.publics.cloak) ananya present+ Euclid present+ Patrick_H_Lauke Patrick: as mentioned, we submitted a tweak to our charter that is currently being discussed/evaluated https://github.com/w3c/charter-drafts/pull/715 smaug present+ ananya has left IRC () Patrick_H_Lauke Patrick: short overview of the rationale behind our recharter, including the relationship between PE and UI events (spec is currently abandoned, there are lots of areas where PE needs to reference aspects of UI events, we're now looking at incorporating them directly in PE - not a power grab, but since UI events is currently not maintained, and we rely on things being defined algorithmically e.g. for "retargeting Patrick_H_Lauke events when a node disappears") Patrick_H_Lauke Patrick: also explanation of gesture stuff - we're not trying to define the low level "how do UAs identify/decide what is a gesture", we're more interested in sketching out some basic high level API for authors to be able to detect things like "a swipe left/right" without having to code these from basic principles. similar to something like the old hammer.js library kagami has joined (~kagami@6b13c2d6.publics.cloak) Patrick_H_Lauke Patrick: we're a small nimble group, but always happy for more participation. workload is fairly low atm, though may ramp up a bit with new areas we want to look at. Our repo https://github.com/w3c/pointerevents smaug https://github.com/w3c/pointerevents/issues/559 mmocny has joined (~mmocny@6b13c2d6.publics.cloak) Patrick_H_Lauke Patrick: was hoping to have mustaq here for more clarification, but... Patrick_H_Lauke # TOPIC: Web Platform Tests - making a list of which tests need to be reviewed/revised kagami has left IRC () kagami has joined (~kagami@6b13c2d6.publics.cloak) Patrick_H_Lauke Patrick: we still have a lot of tests that are red. partly this is due to tests that relate to features that we've now removed (directional touch-actions, which we've moved out of PE3 again and deferred to PE4 due to lack of support beyond Chrome), and some issues that appear to be down to test harness itself Patrick_H_Lauke Olli: yes, from Firefox's side, anything to do with "pen" pointer has issues / fails Patrick_H_Lauke Patrick: was hoping to have mustaq here with us today, as he's been doing sterling work on compiling our list Patrick_H_Lauke Patrick: at last meeting, we discussed possibility of tagging tests somehow, so we can get a subset that is relevant just for PE3 to facilitate the path to REC Patrick_H_Lauke Patrick: so what's best way forward? should we try and go through things here now? Patrick_H_Lauke Olli: possibly better to do offline first. If we remove/exclude things related to pen, remove the tests related to touch-action values we removed, remove the ones that appear to be due to broken harness... Patrick_H_Lauke Patrick: ...and if i recall, some tests like pointerlock are in here, but they don't actually test anything from PE, just "it happens to use pointer events, but testing aspects that aren't" Patrick_H_Lauke Q from observer: so what is the plan for making separate list of tests? folders? marking as tentative? Patrick_H_Lauke Olli: we're looking at a few options, hoping to see what other groups are doing Patrick_H_Lauke Patrick: "tentative" was discussed in our last meeting, but it's perhaps not quite right - it's reserved for things that don't have a spec yet, whereas we want to use if for "these are for level 4". doesn't appear to be a concept of "this test only for PE 1, 2, 3, but not 4" Patrick_H_Lauke Olli: some work may need to be done with filenames, but then we have problem of breaking references smaug Some of the tests are part of interop-2025, and https://wpt.fyi/results/pointerevents?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2023-events looks rather green. (Yes, that is 2025, even though it says 2023) Patrick_H_Lauke ACTION: for next meeting work on a plan forward to tackle list of WPTs - excluding ones that are PE4, check which ones are down to harness problems, etc kagami has left IRC () Patrick_H_Lauke Patrick: not sure when Mike Smith (tm) is planning to pop in, but he said he had some information regarding UI events way forward. might see him in coffee break, so let's leave that item until then Patrick_H_Lauke # TOPIC: touch-action logical values (including directional, but worst case just existing PE3 ones) Brandel has left IRC () Patrick_H_Lauke Patrick: did some early work on this ages ago, got a branch, but likely conflicting by now kagami has joined (~kagami@6b13c2d6.publics.cloak) Patrick_H_Lauke Patrick: relates to https://github.com/w3c/pointerevents/issues/505 and https://github.com/w3c/pointerevents/issues/272 Patrick_H_Lauke Patrick: context is that PE contains touch-action values, these have been unchanged since what became PE Level 1 at the time microsoft submitted this as spec Patrick_H_Lauke Patrick: includes things like pan-x/pan-y. but those may not make sense/aren't flexible enough when working in non-LTR writing systems Patrick_H_Lauke Patrick: even though i'm not a super expert, i took a naive approach of looking at how some other CSS specs used logical values, rather than absolute directional values, and what that could look like in PE adekker has joined (~uid727463@6c65f1b9.public.cloak) Patrick_H_Lauke Patrick: not *replacing* the existing values, but complementing them with something logical that doesn't relate to direction, but rather to column/row (which changes dynamically based on writing system) Patrick_H_Lauke Patrick: draft PR for it was here https://github.com/w3c/pointerevents/pull/496 smaug https://www.w3.org/2025/04/10-i18n-minutes.html#215e Patrick_H_Lauke Olli: question if this is an actual real-world problem - what are the use cases - or if it's more a case of spec "purity" Patrick_H_Lauke Patrick: I could envisage it making sense even from a practical application. for instance, on touch device / mail client, swipe left on an email to get more options ... when it's LTR. when it's RTL, may make more sense to have the swipe the other way to the right. or say you want to do something "along the axis of the text", being able to define it so it works both for horizontal laid out text and vertical text s Patrick_H_Lauke ystems kagami has left IRC () Patrick_H_Lauke Patrick: from memory, when we last discussed this in our group in Jan 2024, Rob (Flack) had some concern about the direction-specific ones Patrick_H_Lauke Patrick: as it wasn't clear if the direction (e.g. pan-block-start) meant it's a pan TOWARDS the block start or AWAY FROM the block start Patrick_H_Lauke Patrick: but arguably the same problem already exists with touch-action direction values ... like pan-left/pan-right/pan-up/pan-down ... does it mean panning TO or FROM those Patrick_H_Lauke Patrick: problem was that i took inspiration form CSS specs for margin/padding/etc, and those are...static, they only refer to the position Patrick_H_Lauke Patrick: perhaps next sensible action would be to flesh out this draft PR some more, include actual simple diagrams (animations?) that make it clearer, then trying to sync up again with i18n and csswg about these Patrick_H_Lauke ACTION: revisit #496 to check for conflicts, and to add even rough at this stage diagrams/animations Patrick_H_Lauke Olli: we may need to then pass extra info, as panning happens in different process. CAN use things like (dir) to craft CSS that's specific to LTR/RTL already... Patrick_H_Lauke Patrick: ...but would be good not to require authors to rely on jumping through burning hoops smaug https://issues.chromium.org/issues/457794569 Patrick_H_Lauke # TOPIC: bonus...a chromium bug flagged by PLH kagami has joined (~kagami@6b13c2d6.publics.cloak) Patrick_H_Lauke Olli: [explains the problem - relates to touch-action: auto and how much of the user agent's magic - there's nothing TO pan here, so should not swallow/digest pan events - is spec'd/left up to UAs) Patrick_H_Lauke ACTION: Olli and Mustaq to duel it out Patrick_H_Lauke Michael Moony: specifically keen on some of the gesture metrics. in event timing spec we have concept of interaction, interaction to next paint (popular core web vital). two ideas: are gestures are just new things, would be cool to treat these as interactions. but even for old-fashioned tap, many events fire ... would gesture be an umbrella for all these discrete events? and should we be working closer Patrick_H_Lauke Olli: our planned event are VERY high level, so not sure we can go much further Patrick_H_Lauke Michael Moony: i would love some way to logically group a stream of events to treat it as a single "interaction" Brandel has joined (~Brandel@6b13c2d6.publics.cloak) Patrick_H_Lauke Michael Moony: would love gesture id Patrick_H_Lauke Patrick: so you'd be able to relate individual events to gestures, and vice versa. almost sounds a bit like what we did for coalesced events Patrick_H_Lauke Olli: you may not get the individual events though, if the UA consumes the gesture mmocny has left IRC () Patrick_H_Lauke Patrick: we're at the stage currently where everything's still up for grabs. I'd suggest if you have use cases or ideas, feel free to send them to us. even if you wanted to join one of our meetings (without formally joining the group), feel free to reach out, we're always happy to have guests Patrick_H_Lauke [Michael and Olli discuss some more specifics] m-alkalbani has left IRC () kagami has left IRC () Brandel has left IRC () saji has joined (~saji@6b13c2d6.publics.cloak) Steven has joined (~Steven@6b13c2d6.publics.cloak) Patrick_H_Lauke # TOPIC: Dan Applequist (ABQuist) to talk to us about AB initiative m-alkalbani has joined (~malkalbani@6b13c2d6.publics.cloak) Patrick_H_Lauke present+ torgo Patrick_H_Lauke Dan: used to be TAG - the "what"; now AB - the "how", process Patrick_H_Lauke Dan: Process document has already been through reviews to simplify, but can simplify further. addressing criticism of it still being difficult to engage with kagami has joined (~kagami@6b13c2d6.publics.cloak) Patrick_H_Lauke # TOPIC: UI Events and way forward to integrate at least parts of it into PE4 Patrick_H_Lauke Baran (meta): question about pointer events for AR/XR devices Patrick_H_Lauke Baran: we have two pointer devices that support hover AND multi-pointer events Patrick_H_Lauke Baran: we use pointerType=touch, but can cause confusion when dispatching certain events and websites break Patrick_H_Lauke Baran: what are thoughts on allowing direct manupulation for non-touch. either for mouse, or even another new pointerType? Patrick_H_Lauke Patrick: touch-action has always been a misnomer. we do think that direct manipulation should be possible with any pointerType. but tricky for compat...particularly if sites don't expect it Patrick_H_Lauke Patrick: problem with inventing new pointerType is that a site may not recognise it, if they're coded to listen to specific pointerTypes only Patrick_H_Lauke Patrick: [summarising a bit - discussing with Baran how the problem with things like "how can we support multiple pointers that hover" is if you still listen to legacy mouse events, which are explicitly spec'd to only work on the primary. but if you abandon those and move to just listen to pointer* events, then it's up to YOU as author how you deal with multiple pointers] Patrick_H_Lauke Patrick: [this is actually when you then may have opposite problem ... you listen to pointer events and then check the primary boolean to determine if it's the primary pointer] Patrick_H_Lauke Olli: checking the inout device capabilities spec (that Baran mentioned as a possible workaround) https://developer.mozilla.org/en-US/docs/Web/API/InputDeviceCapabilities_API - spec last updated 4 years ago, and Chromium only Patrick_H_Lauke Patrick: i think that came about before pointer events was even a thing, i remember looking at it in my "getting touchy" presentation as part of the "how to beat the 300ms delay between touchup and click" to de-dupe events firing Patrick_H_Lauke https://wicg.github.io/input-device-capabilities/ Patrick_H_Lauke Olli: i'll see if Mike (tm) Smith is around. we did discuss UI events spec on Monday already, and in another meeting...we also need mustaq, so we can probably leave this topic for another time Patrick_H_Lauke Patrick: so just to mention that, as discussed, I did create a new branch for PE+UI events stuff https://github.com/w3c/pointerevents/tree/pointerevents%2Bui-events Patrick_H_Lauke Patrick: based on main/PE4 Patrick_H_Lauke Patrick: main reason i made it a separate branch is that this gives us freedom to experiment and start putting bits in place that may be a bit rough initially, without the need to always make sure it makes sense (that's what PE4/main is for) Patrick_H_Lauke Patrick: once we're happy with the shape of PE+UI, we can then merge that back into PE4/main Muadh Al Kalbani: suggestion to include examples of how to use pointer events correctly/well to deal with multi-pointer cases - e.g. example of "basic multipointer drawing application" -- 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 December 2025 15:25:01 UTC