W3C

– DRAFT –
PEWG

03 February 2021

Attendees

Present
Patrick_H_Lauke, smaug
Regrets
-
Chair
Patrick H. Lauke
Scribe
Patrick_H_Lauke

Meeting minutes

Patrick: as it's only me and Olli, and Olli was present at that call, we can save ourselves discussion on the first items about new charter/future of PEWG after PE3

will remind Google to review on mailing list. Will ask PLH when the best time is to run the CfC for new charter

Specify exactly how event coalescing works

https://github.com/w3c/pointerevents/issues/328

Olli: I commented on the issue. it's tricky. in Gecko, mouse events coalescing happens in browser on desktop. but on Android, we can use APIs closer to OS events

It can be an implementation detail

Patrick: also, I get feeling that this is area that we wanted to avoid due to IPR concerns / out-of-scope for our group

Olli: being too precise may also hinder future implementations/alternative implementations

Patrick: just checking our (new) charter

Olli: it doesn't really squarely fall in any of our out-of-scope areas directly. Might be worth asking @smfr if there is a specific area of implementation he had in mind. let me add a comment

Patrick: sure. it won't happen for PE3, but once we move to evergreen model we could look at this further

Click event while a pointer event is captured

https://github.com/w3c/pointerevents/issues/75

Olli: just added a comment there as well. This was about removing a hack due to the way Blink originally behaved. I'll check what the most recent behaviour is, and depending on that will move ahead with potentially making update to spec accordingly.

Could we ever do implicit capture for all pointer types?

https://github.com/w3c/pointerevents/issues/125

Patrick: the state of the issue at the time was "we need to run some more tests, has compat issues though". Wonder if it's now too late to make this breaking change. I personally quite like the model we have, where touch is implicitly captured mainly because of the specific nature of touch interface, finger used for both activating things and scrolling, and it's what authors are used to from touch events. for mouse though, authors

are used to having no capture and having to hack things, e.g. adding listeners to the whole body on mousedown and removing them again on mouseup. so having to explicitly capture the pointer doesn't seem like a big ask to me

and being a breaking change, it might well be too late now to do it, unexpected, and likely to break more things as more devs now starting to use PE

Mouse back/forward buttons: page navigation or JS events?

https://github.com/w3c/pointerevents/issues/191

Olli: just been testing. On Linux the buttons fire on the down event. On Windows, they fire on the up. Problem with trying to define in PE is that we'd have to standardise this and get buy-in from platforms themselves, which is trickier.

Patrick: also, do these buttons currently even fire MOUSE events? let alone pointer events

Olli: from testing now, don't seem to fire mouse events

Patrick: in which case i'd say this is something more fundamental, at UI events level. not something we should spec out in PE. there is an open issue with UI events, so let's see what happens there first. Once discussion has happened THERE, we can then decide if the events that do get fired (if they decide they should) are pointer events

Olli: or some higher level event like contextmenu

Patrick: propose closing this and waiting to see what UI events discussion does

Olli: agreed

Patrick: closing issue

AOB

Patrick: as there's no other issues, let's keep this short. I will reach out to Google to see if they're still keen to push this over the last few hurdles to PE Level 3, and with PLH about when to do the CfC to have an official go-ahead for the new model/charter. Meanwhile, speak to you in 2 weeks' time.

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

Diagnostics

Maybe present: Olli, Patrick