Minutes from Pointer Events WG call 19 Feb 2020

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