- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 19 Feb 2020 17:18:12 +0000
- To: public-pointer-events@w3.org
Dear all, minutes from today's call are available on https://www.w3.org/2020/02/19-pointerevents-minutes.html and copied below: Pointer Events WG 19 Feb 2020 Agenda https://lists.w3.org/Archives/Public/public-pointer-events/2020JanMar/0013.html Attendees Present Patrick_H_Lauke, Olli_Pettay, NavidZ, dlibby Regrets Chair Patrick H. Lauke Scribe Patrick H. Lauke Contents Topics 1. add altitudeAngle/azimuthAngle https://github.com/w3c/pointerevents/pull/316 2. changing click and auxclick to PE https://github.com/w3c/uievents/pull/259 3. Define event order relative to RAF? https://github.com/w3c/pointerevents/issues/9 4. Should DragEvent be upgraded to a PointerEvent? https://github.com/w3c/pointerevents/issues/106 5. setPointerCapture should be disabled in sandboxed iframes by default 6. pointer trails https://github.com/w3c/pointerevents/issues/204 Summary of Action Items Summary of Resolutions <scribe> Scribe: Patrick H. Lauke add altitudeAngle/azimuthAngle https://github.com/w3c/pointerevents/pull/316 Patrick: giving broad outline of what the intention of the PR is. any feedback? NavidZ: we need more detail for implementers on how to translate between different models Olli: we also need relevant tests NavidZ: I can take care of tests Patrick: I saw that there's at least a python implementation of how to convert from one set of variables to the other in github wasn't sure if we wanted big formulae right in the middle of the spec prose. do we want appendix? NavidZ: some other specs have formulae, like VR one, but either way is fine as long as the spec has some formula for implementers to follow Olli: also do we want to define what happens when an author generates a PE and they only provide one set of these attributes? should they be empty or be calculated? Patrick: that's part of my handwavy note about "when a PE is created with only one set, the user agent MUST..." NavidZ: also what to do if author provides both sets, and they don't match / are incorrect Patrick: we could either say the user agent is ok with generated events even if the properties are nonsensical/don't match, OR we could say it rejects the whole event and throws and exception or something? not sure what happens in similar scenarios for other event models Olli: no, no exceptions etc are fired. user agents don't care what values you provide Patrick: ok, so we can say that if the author provides both, then user agent just creates the event with what author provided, and it's author (web dev's) responsibility to make sure they match Daniel: what is the concern? somebody creating a script that generates events, and those events are then handled by some other code? Patrick: yes, if i was just doing this for my own site that i fully control, i may just say "i only work in tiltX/tiltY so i'll just leave altitudeAngle/azimuthAngle out and don't care". but if they were doing something like a utility library that fires events that OTHER scripts then might consume, then yes they may generate events with both sets <scribe> ACTION: Patrick to add appendix with some initial rough conversion formula (will need somebody to check it as maths not his forte); add reference to it from the note; add to note about events generated with all 4 properties, that UA does not need to check that the two representations are equivalent (may have different rounding or similar), that it's then just taken at face value <NavidZ_> https://github.com/w3c/pointerevents/issues/292 - changing click and auxclick to PE https://github.com/w3c/uievents/pull/259 <NavidZ_> This is what I meant: https://github.com/w3c/pointerevents/issues/100 NavidZ: discussed this with UIEvents folks / Gary. waiting for resolution on this, and then will make matching PR in PE we will have this enabled in Chrome after that (?) NavidZ: couldn't find normative definition for contextMenu Daniel: it's defined in HTML spec Olli: no, only vaguely mentioned Daniel: it says it's a mouse event, so we probably want/need to change that there as well Olli: yeah we'll need to change HTML spec too <smaug> https://html.spec.whatwg.org/#events-2 NavidZ: fair enough, will need to check/change the table there to point to right definition Define event order relative to RAF? https://github.com/w3c/pointerevents/issues/9 Patrick: is this still relevant and/or do we want it in PE or is this more at home in UIEvents? Olli: this might be hard depending on how UAs like blink do things, but not necessarily something that is true in other browsers so might make it harder to define and i don't want to force this (animation frames etc) all the time NavidZ: we actually have handwavy mention in spec in our coalescedEvents section where UA *could* delay based on other events like RAF don't think we need to spec anything more RESOLUTION: close the issue / our spec is handwavy enough on the topic Should DragEvent be upgraded to a PointerEvent? https://github.com/w3c/pointerevents/issues/106 Patrick: reminder: not expecting to fully discuss this, but just if this is something still valid/that we want to work on or not NavidZ: i think this could do with some more discussion. let's see how it goes with issue #100 as this is similar/related Olli: this also makes it more complex as this changes the prototype chain <NavidZ_> https://github.com/w3c/pointerevents/issues/16 RESOLUTION: we'll discuss this further at next meeting setPointerCapture should be disabled in sandboxed iframes by default NavidZ: we already made a change regarding active document since then, so this should now be ok/can be closed Olli: we have quite a few editorial issues around getCoalesced - need to see what's now actually adopted in UAs, what makes more sense now that we've seen some initial roll-out, etc NavidZ: happy to also change Blink behaviour, as we haven't had big uptake does Firefox have coalesced events? Olli: yes <NavidZ_> https://github.com/w3c/pointerevents/issues/223 <NavidZ_> https://github.com/w3c/pointerevents/issues/277 NavidZ: just asking now - are people here happy to only expose pointerrawupdate and getcoalescedevents only on secured origins? as they could otherwise expose data for fingerprinting etc? Olli: i don't object NavidZ: ok, i'll see what i can do in chromium and do an initial PR for the spec <scribe> ACTION: NavidZ to make PR about pointerrawupdate and getcoalescedevents only on secured origins pointer trails https://github.com/w3c/pointerevents/issues/204 NavidZ: we need to decide if we want to extend our charter for this (as this is out of scope for our current charter), or leave it to next version, or a separate spec? Patrick: my understanding is we can't change charter mid-course, so it would have to be PEv4 at best. still feels related, but "adjacent" to PE, not PE strictly itself NavidZ: Daniel you happy moving to WICG or similar? Daniel: yes happy to move forward in that direction [NavidZ gives some feedback about pointer trails to Daniel] Patrick: should we close https://github.com/w3c/pointerevents/issues/204 then for now? NavidZ: yes Daniel: yes Olli: yeah RESOLUTION: issue 204 closed NavidZ: so what are our planned next steps? make more changes and publish another working draft? Patrick: yes, basically I think we have most of the BIG things we wanted to have in v3, now we just want to mop up any remaining open issues. make changes, keep publishing more iterations, until we think we're at the point where we can push the spec further up the W3C process chain and get to REC (not in a particular rush myself, but would be good to finalise as i think we're running out of steam, and have most of the stuff in there. there MAY be a PEv4, or any new big changes may be adjacent specs, or higher/lower specs like UIEvents...) Patrick: I'd also at some point like to discuss Touch Events v2, would love to see what we could do to push this from just a CG note to an actual spec, but politically thorny issue of course [Patrick also mentions PEP, and call for help to sort out this old abandoned codebase to at least wrap it up for a graceful archival - will send to mailing list with more details] in meantime then, we have actions from this meeting, and also please look over existing open issues (some quite old) on GH and let's carry on triaging Summary of Action Items [NEW] ACTION: NavidZ to make PR about pointerrawupdate and getcoalescedevents only on secured origins [NEW] ACTION: Patrick to add appendix with some initial rough conversion formula (will need somebody to check it as maths not his forte); add reference to it from the note; add to note about events generated with all 4 properties, that UA does not need to check that the two representations are equivalent (may have different rounding or similar), that it's then just taken at face value Summary of Resolutions 1. close the issue / our spec is handwavy enough on the topic 2. we'll discuss this further at next meeting 3. issue 204 closed -- 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, 19 February 2020 17:18:27 UTC