- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 14 Jan 2026 16:30:29 +0000
- To: public-pointer-events@w3.org
Dear all, minutes from today's call are at https://www.w3.org/2026/01/14-pointerevents-minutes.html and copied below: PEWG 14 January 2026 Agenda: https://www.w3.org/events/meetings/bc0bed33-fd93-40a6-95bb-10f27c641863/20260114T100000/ IRC log: https://www.w3.org/2026/01/14-pointerevents-irc Attendees Present flackr, mustaq, Patrick_H_Lauke, smaug, vmpstr Chair: Patrick H. Lauke Scribe: Patrick H. Lauke Contents * Recharter w3c/strategy#515 * Follow-up from UI Events meeting https://docs.google.com/document/d/1iRFgqtReyomoCwZFEdRUdoW1ManD5t656CVUGJm7Xos/ * WPTs # Recharter w3c/strategy#515 Patrick: all wording changes to the charter that we discussed/were raised have been done. last outstanding piece is a rough prototypical "here's the list of events for gestures we want to cover" [some discussion on which types of events we want - rotate/zoom and possibly swipe, or is swipe the same-ish - moving centroid] ACTION: Patrick to draft gesture event outline for next meeting # Follow-up from UI Events meeting https://docs.google.com/document/d/1iRFgqtReyomoCwZFEdRUdoW1ManD5t656CVUGJm7Xos/ plh: i have a PR for UI events w3c/uievents#411 to make sure it removes the bits we're taking into PE plh: still need to figure out pointerlock (trying to get webapps to move that out) plh: we'll keep linking to the external algos. once moved, the link will update plh: some like focusable area and click-focusable defined in HTML,but they're not exporting them. we can either link, or ask HTML spec to export plh: looked a bit at default action idea plh: if you look at DOM spec it handles the idea of default action already. just that it calls it activation behaviour olli: that's only for click plh: there's different types ... activation behaviour, and LEGACY activation behaviour. trusted behaviour, cancelled not set to true. plh: all we need to do is define what the legacy activation behaviours are for click, and what the activation behaviours are for all other cases plh: am i correct? somebody double-check my understanding <mustaq> https://w3c.github.io/uievents/#event-type-keydown plh: if i understand the dispatch behaviour, that's covered. legacy activation for click, and the others are for other events mustaq: in the default action of keydown it links to the activation behaviour "Varies: beforeinput and input events; launch text composition system; blur and focus events; keypress event (if supported); activation behavior; other event" plh: i believe one way out then is not to talk about default action, but talk about activation behaviour olli: but activation behaviour is specific to click. it assumes trusted events... rob: i believe it covers just things like click. doesn't handle text selection, or scrolling, or similar plh: then way forward may be to ask for a hook to handle these other cases, and we hook into that, rather than patching the dispatch algo ourselves olli: https://dom.spec.whatwg.org/#:~:text=Let%20isActivationEvent%20be%20true%2C%20if%20event%20is%20a%20MouseEvent%20object%20and%20event%E2%80%99s%20type%20attribute%20is%20%22click%22%3B%20otherwise%20false%2E plh: we get dispatch algo updated to take into account those default actions. or we clarify that these are actions after the dispatch rob: the action does happen in between events though... olli: but after the relevant event was sent... rob: yes, but not after all events...so there's some specific order/timing rob: no strong feeling if it needs to be in the dispatch, or after the dispatch... plh: assuming it's trusted, cancelable flag set to false, it then happens after dispatch... plh: i'll see what that looks like, but if not we need to modify dispatch... plh: hit-test algo is only used by mouse events. i moved it to PE, but then realised it conflicts with our glossary. removed our glossary... rob: it should all be the same thing. think for longest time it didn't exist other than SVG plh: DOMActivate - as part of legacy bits, the DOMActivate is still present in ui events. but you're not supposed to use that anymore in preference of click. do we want it, or leave it? legacy section olli: should probably go to HTML... Patrick: yeah from memory this is the "click is not device agnostic as a term, let's invent something new" but that was too late. for history, still good to have that somewhere. probably HTML plh: so somebody should make a PR/proposal to HTML spec. if you know a contact with an editor at HTML spec, ask them... olli: not seeing any WPTs for DOMActivate... plh: i'll bring that up to the next UI events meeting next month plh: beyond that i think i'm done with the PR plh: we'll wait for next UI events meeting to merge plh: WPTs ... any idea what best approach might be? if we move them, would things break? mustaq: i'm worried about links to tests breaking rob: we could leave behind a text file pointing to the new location? i think it's nice to have the structure of WPT match the specs mustaq: should we wait for WPT move until things settle down? rob: spec move doesn't affect WPT. so what do we need to wait for? mustaq: should we wait until the ui events part is merged into PE and baked in plh: going to make PR against WPT. then we know we have all components (spec change, WPT), then we can decide on sequencing plh: other consideration is MDN, as they link to tests and specs mustaq: also caniuse etc plh: need to make a list of what will be affected. like... for MDN, does it repoint automatically, or does it need a PR rob: we know what the anchor links are...maybe we can add in a mention about the move and point there olli: and that needs to only be a temporary thing plh: making a tasklist on the PR olli: caniuse seems to link to MDN mustaq: there's links to actual specs mustaq: there's a webDX community group. maybe reach out to them too <flackr> mdn/content and web-platform-dx/web-features ? rob: two files in web-features that will need updating. just a one-line change <flackr> https://github.com/web-platform-dx/web-features/blob/879469aaa3a54cb5c1c453e18f9b08548067f070/features/mouse-events.yml#L3 and https://github.com/web-platform-dx/web-features/blob/879469aaa3a54cb5c1c453e18f9b08548067f070/features/wheel-events.yml#L4 plh: link those from the PR, if easy enough i can make a PR for those too mustaq: any other repos in web-platform-dx that might be relevant/need updates? <mustaq> https://github.com/web-platform-dx rob: nothing seems to come up from a search mustaq: question about the larger picture - how will the PE spec itself "work" structure wise / logically olli: maybe we should add a note warning that things are still in progress rob: keep sections, but note that it's WIP <mustaq> +1, a note for each top level section make sense. Patrick: was also thinking that we may need an update to the prose at the start of the spec, to explain why all of a sudden we also have mouse and wheel stuff # WPTs mustaq: i looked into the non-standard tests ... we essentially we don't the non-standard part inthe stable part ofthe spec. will do a PR plh: still need to do implementation report, taking results and then filtering things we don't cover in the spec mustaq: moving the non-standard tests that are in tentative, and ignore the touch-action ones for values that are not in level 3, that should be complete # Summary of action items * Patrick to draft gesture event outline for next meeting -- 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, 14 January 2026 16:30:40 UTC