<scribe> Scribe: Patrick H. Lauke
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
<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
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
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
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
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
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: Patrick_H_Lauke Olli_Pettay NavidZ dlibby No ScribeNick specified. Guessing ScribeNick: Patrick_H_Lauke Found Scribe: Patrick H. Lauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2020JanMar/0013.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: navidz patrick WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]