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
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
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?
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?
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
Patrick: closing issue
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.