Minutes from Pointer Events WG call 17 August 2022

Dear all,

the minutes from today's brief meeting are at 
https://www.w3.org/2022/08/17-pointerevents-minutes.html and copied below:

17 August 2022



flackr, mustaq, Patrick_H_Lauke, smaug

Chair: Patrick H. Lauke
Scribe: Patrick H. Lauke

* Order of pointerover/enter/move and corresponding mouse events is 
different on browsers https://github.com/w3c/pointerevents/issues/454
* Heartbeat: Clarify what the target of the click event should be after 
capturing pointer events https://github.com/w3c/pointerevents/issues/356
* Web Platform Tests

# Order of pointerover/enter/move and corresponding mouse events is 
different on browsers https://github.com/w3c/pointerevents/issues/454

Mustaq: have sketches/diagrams ready, but would be better as animation. 
Rob can help with making it an animated gif.

Mustaq: the second point of the question, the ordering may not be so 
critical because authors should either look at pointer events OR mouse 
events, not mixing and matching

Rob: while I agree this is more a UI events issue, we should have some 
clarity/order defined somewhere

Olli: problem may be compounded by legacy scripts relying on order of 
mouse events being extended to then also work with PE

Olli: but i also don't think there's any bugs at the moment

Mustaq: down, up, and move events imply where over and out get dispatched

Mustaq: we can look at the grouping, but the relative order 
problem...even UI Events spec doesn't define this

Olli: should probably also define what happens with touch events

Rob: can you remove implicit capture? because over/enter/etc rely on 
change of target

<flackr> https://www.w3.org/TR/uievents/#events-mouseevent-event-order

Rob: UI Events does define that the mouse events need to happen in a 
specific order

Olli: that's for mouse. in Firefox, pointermove comes first, then 
pointerover (?)

Mustaq: also needs to deal with bubbling

Mustaq: [mentions case of what happens with over - bubbling - and then 
enter sent directly to the child]

Rob: we should define our relative order for pointerevents in the same 
way that UI events defines it for mouse events

Patrick: but we'd stay silent about how it's then interleaved or not. as 
long as the order is still the same *within the type of events*. if you 
then had legacy script reliant on a specific order for mouse, and you 
upgraded it to use pointerevents instead, the order would still be the 
same and not break. but if you mixed and matched, you're off-roading and 
can't rely on that

Rob: particularly because legacy/compat events are often batched in a 
way only once UA has determined what kind of interaction it is

[discussion of two primary pointers - one mouse, one touch - happening 
at the same time, legacy events jumping from one to the other constantly?]


Rob: don't think any current browsers treat a touch movement on a 
touch-action:none to then immediately fire legacy mouse events

[we say OPTIONAL there, maybe we need to be more forceful and require it?]

[discussion of current Chrome behaviour and when it does/doesn't 
immediately send over/enter on down]

Olli: we should test this more on different browsers

Rob: and probably decide if what we have now is the best possible behavior

Mustaq: let's split this issue into multiple ones (ordering vs touch 

Rob: for ordering (within pointer) we should defer to UI events and 

Mustaq: for the other issue, we should check different browsers with 
regards to touch and mouse legacy events

Rob: i think we say the only compat events we support are click and 
contextmenu, and those then generate equivalent legacy events to 
simulate a mouse going to that location

Olli: if over and enter are supposed to come from move, then Firefox 
behaviour is currently consistent...


<mustaq> The second NOTE here defines canceling behavior of compat mouse 

<mustaq> https://w3c.github.io/pointerevents/#the-pointerdown-event

Patrick: so, at a very high level, do we want to add something to both 
11.2 and 11.3 to mention mouseover, mouseenter, mouseout, mouseleave - 
even if we say something like "over and enter are a side effect/come 
from move", for instance


Rob: i think the boundary events for mouse then they're not interleaved, 
from reading the spec

Rob: should figure out what the differences are between browsers, and 
clearly define the expected order between these events

Rob: if there are browser differences, we're unlikely to see major 
compat issues if we settle on one

Olli: and Safari is so different, I imagine there's no many bugs filed 
against them, otherwise they'd have looked at how chrome/firefox do it 
since they're similar

Mustaq: and we want to look at that OPTIONAL ...

Rob: we should probably decide that it's NOT optional. and make note 
that since these happen after the click (for touch/stylus?) then they're 
clearly not interleaved

Mustaq: we should also look if the cancelling behaviour is normative or 
not. it's a note in 4.2.3

Patrick: yes, we should just make that normative prose

ACTION: Patrick to edit 4.2.3 to make second note actual normative text

ACTION: Mustaq to look at creating animation with Rob's help to clarify 
how legacy events are "ported" from one primary pointer to the other

Patrick: Mustaq did you also say that the original filed issue would be 
best split into two separate issues? and if so want to do that?

Mustaq: I can try yes

ACTION: Mustaq to split issue 
https://github.com/w3c/pointerevents/issues/454 into two separate issues

Patrick: suggest closing 454 and marking it as superseded by the new two 
issues to avoid cross-talk between issues

# Heartbeat: Clarify what the target of the click event should be after 
capturing pointer events https://github.com/w3c/pointerevents/issues/356

Olli: no movement

Mustaq: filed a bug, not heard back

Rob: don't have any reason to think we *can't* do this

# Web Platform Tests

Patrick: made a start, going through all PRs since the last version 
adding a "wpt" label (unless the PR looked clearly like just an 
editorial change). propse that we then all go through these, and 
*remove* the wpt label if we know that something already has a test, or 
something doesn't actually need (or can have) a test. leave a comment on 
that specific PR to just say if you removed it and why. that should then 
leave us with PRs tagged with "wpt" that will definitely *need* a new 
test for them, then we can go from there

ACTION: Patrick to finish tagging PRs, then everybody to look over them 
for next time (and remove "wpt" label where not needed/already covered, 
and comment on the PR accordingly)

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, 17 August 2022 16:06:37 UTC