- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 8 Jun 2022 16:27:56 +0100
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2022/06/08-pointerevents-minutes.html and copied below: PEWG 08 June 2022 Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220608T110000 Attendees flackr, mustaq, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Recently merged: Cleanup and respec fixes https://github.com/w3c/pointerevents/pull/441 * New: Properties firing pointermove and pointerrawupdate https://github.com/w3c/pointerevents/pull/443 * Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 * Side note about touch-events: Reword altitudeAngle/azimuthAngle descriptions in line with PE, add illustrations https://github.com/w3c/touch-events/pull/125 # Recently merged: Cleanup and respec fixes https://github.com/w3c/pointerevents/pull/441 Patrick: all respec bugs have been fixed, and Dom has sent a PR that I merged that made further fixes to respec. so all good # New: Properties firing pointermove and pointerrawupdate https://github.com/w3c/pointerevents/pull/443 [reading over the changes] Patrick: just confirmed that if there's *just* a change of button state (e.g. clicking mouse button making sure there's no other movement), then yes no pointermove is fired https://patrickhlauke.github.io/touch/tests/event-listener.html Rob: concern about situations like drawing applications, fast movements and then lifting mouse button (?) Olli: I think in practice though this will be fine Rob: concerned about what happens when the change of position and button change happen exactly at the same time Patrick: but they'd still be separate events Olli: need to see though what button state would be in the move and the up events [more discussion on the concurrent event case] Rob: maybe we can define which events need to be fired when properties change (?) Rob: but for this, it seems fine Olli: agrees ACTION: merge the PR # Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 Patrick: just a heartbeat, to keep this on people's agenda Patrick: no activity so far Rob: maybe we can add something to our schedule to look at this Mustaq: things that need to be fixed in Chrome, yes, but no progress # Side note about touch-events: Reword altitudeAngle/azimuthAngle descriptions in line with PE, add illustrations https://github.com/w3c/touch-events/pull/125 Patrick: just as a side note that the touch events spec now mirrors the wording used in the pointer events spec for altitudeAngle and azimuthAngle, including the diagrams. one notable difference of course is the bit where we decided to differ in PE for the default value when pen is perpendicular, so TE spec now has a matching but opposite note pointing out how it differs from PE Patrick: Mustaq/Rob, you ok for next meeting to look at the further clarification about what exactly happens for concurrent move and up/down events (from our first topic)? [Rob/Mustaq agree] Patrick: thank you all, catch you again in two weeks' time -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 8 June 2022 15:28:10 UTC