- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 1 Apr 2020 16:48:55 +0100
- To: public-pointer-events@w3.org
Dear all, minutes from today's call are available on https://www.w3.org/2020/04/01-pointerevents-minutes.html and copied below: PEWG 01 Apr 2020 Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2020JanMar/0046.html Attendees Present smaug, patrick_h_lauke, NavidZ Regrets Chair Patrick H. Lauke Scribe Patrick H. Lauke Contents Topics - Change the type of click, auxclick, and contextmenu to PointerEvent https://github.com/w3c/pointerevents/pull/317 - Add secure context criteria to pointerrawupdate and getCoalescedEvents https://github.com/w3c/pointerevents/pull/318 - add altitudeAngle/azimuthAngle https://github.com/w3c/pointerevents/pull/316 Summary of Action Items Summary of Resolutions <scribe> Scribe: Patrick H. Lauke <NavidZ_> I'm trying to join <NavidZ_> +NavidZ - Change the type of click, auxclick, and contextmenu to PointerEvent https://github.com/w3c/pointerevents/pull/317 Navid: chrome was going to do it now, but fear of breaking things, so we're holding off for now in future, once we enable and get some compat data, we can take it forward - Add secure context criteria to pointerrawupdate and getCoalescedEvents https://github.com/w3c/pointerevents/pull/318 Navid: similar, we're waiting for Chrome to enable to get data, then we can see Olly: sounds good, and we wouldn't want to make the change in Firefox at this point in time either - add altitudeAngle/azimuthAngle https://github.com/w3c/pointerevents/pull/316 Patrick: it appears i got myself confused with the twist aspect, but i see somebody (from google team) reviewed the maths Navid: looking at tilt direction, we need agreement on which way the Y axis goes - looking at the graphics in spec, it seems that Y axis points up, but it should point down, and that seems consistent with data we get back Patrick: testing in chrome on surface, galaxy note 2, wacom, the webgl demo i use works consistently. i think graphic in https://w3c.github.io/pointerevents/ is misleading wording already says "A positive tiltY is towards the user" Navid: need agreement on when pen is lying [essentially flat on plane, pointing to 3 o'clock] Patrick: that would be azimuth 0. and then going clockwise, it increases up to 2 PI https://developer.apple.com/documentation/uikit/touches_presses_and_gestures/illustrating_the_force_altitude_and_azimuth_properties_of_touch_input https://www.raywenderlich.com/1407-apple-pencil-tutorial-getting-started#toc-anchor-006 (further discussion on specific aspects/clarifications about clockwise/counter-clockwise, specific situations/edge cases) <NavidZ_> https://wpt.fyi/results/touch-events/idlharness.window.html?label=experimental&label=master&aligned <NavidZ_> This is the test for azimuth and altitude of touch events Navid: should we just release the first part of the pull request that adds those values, but iterate further on the explanation of how to convert Patrick: let's just release in one go. I'll spend more time refining this/making sure it matches reality Navid: touch events has those values too, but it seems no browser implemented them does Firefox plan to support? nobody seems to support these Olly: maybe we should remove them then Patrick: I thought Safari support it (maybe just on iPad Pro) can we find out who/when it was added to the Touch Events spec? I#'ll investigate further Olly: navid when testing tiltX/tiltY, were you also testing old Edge how it behaved? Patrick: from my testing at the time (with the webgl demo) old Edge behaved consistently <smaug> https://developer.apple.com/documentation/webkitjs/touch https://github.com/w3c/touch-events/commit/0d0ab1729d11c39281663cbdaf4a66e5fbecbe81 (exploring who originally added the variables to TE) Patrick: i'll investigate (possibly through contacts that have an actual iPad Pro + Pencil) what the situation is (as Rick Byers added those properties to TE, I assume it's because they were actually exposed "in the wild" and he didn't just make them up). Desire is to have the matching ones in PE to be exactly the same, essentially, so there's no conversion needed unnecessarily when going from TE model to PE model for those If nothing else to discuss, I'd say let's close call for now. I'll carry on iterating over the pull request for azimuth/altitude, check the maths, add prose for edge cases (e.g. perpendicular) and check my clockwise/counterclockwise wording etc. Next call should be in 2 weeks. -- 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, 1 April 2020 15:49:11 UTC