IRC log of pointerevents on 2022-08-17

Timestamps are in UTC.

14:48:23 [RRSAgent]

RRSAgent has joined #pointerevents

14:48:23 [RRSAgent]

logging to https://www.w3.org/2022/08/17-pointerevents-irc

14:49:16 [Patrick_H_Lauke]

Meeting: PEWG

14:49:20 [Patrick_H_Lauke]

Chair: Patrick H. Lauke

14:49:37 [Patrick_H_Lauke]

Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220817T110000

14:49:48 [Patrick_H_Lauke]

Scribe: Patrick H. Lauke

14:49:56 [Patrick_H_Lauke]

ScribeNick: Patrick_H_Lauke

14:50:00 [Patrick_H_Lauke]

present+ Patrick_H_Lauke

15:00:11 [flackr]

flackr has joined #pointerevents

15:00:42 [smaug]

(just a sec)

15:01:46 [Patrick_H_Lauke]

trying to connect but failing, maybe i'm holding it wrong

15:02:17 [mustaq]

Present+ Mustaq

15:02:58 [flackr]

present+

15:03:33 [Patrick_H_Lauke]

present+ smaug

15:03:38 [Patrick_H_Lauke]

present+ mustaq

15:04:27 [Patrick_H_Lauke]

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

15:06:54 [Patrick_H_Lauke]

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

15:07:56 [Patrick_H_Lauke]

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

15:08:42 [Patrick_H_Lauke]

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

15:09:16 [Patrick_H_Lauke]

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

15:09:28 [Patrick_H_Lauke]

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

15:10:38 [Patrick_H_Lauke]

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

15:11:25 [Patrick_H_Lauke]

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

15:11:43 [Patrick_H_Lauke]

Olli: should probably also define what happens with touch events

15:12:09 [Patrick_H_Lauke]

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

15:13:13 [flackr]

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

15:13:54 [Patrick_H_Lauke]

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

15:14:36 [Patrick_H_Lauke]

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

15:14:52 [Patrick_H_Lauke]

Mustaq: also needs to deal with bubbling

15:16:31 [Patrick_H_Lauke]

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

15:18:14 [Patrick_H_Lauke]

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

15:19:41 [Patrick_H_Lauke]

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

15:20:13 [Patrick_H_Lauke]

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

15:21:35 [Patrick_H_Lauke]

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

15:24:37 [mustaq]

https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events

15:25:10 [Patrick_H_Lauke]

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

15:25:56 [Patrick_H_Lauke]

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

15:26:56 [Patrick_H_Lauke]

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

15:28:38 [Patrick_H_Lauke]

Olli: we should test this more on different browsers

15:28:52 [Patrick_H_Lauke]

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

15:29:19 [Patrick_H_Lauke]

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

15:29:36 [Patrick_H_Lauke]

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

15:30:29 [Patrick_H_Lauke]

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

15:31:17 [Patrick_H_Lauke]

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

15:34:27 [Patrick_H_Lauke]

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

15:35:22 [Patrick_H_Lauke]

Patrick: https://w3c.github.io/pointerevents/#mapping-for-devices-that-support-hover

15:38:39 [mustaq]

The second NOTE here defines canceling behavior of compat mouse events:

15:38:40 [mustaq]

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

15:38:44 [Patrick_H_Lauke]

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

15:38:45 [flackr]

https://w3c.github.io/pointerevents/#tracking-the-effective-position-of-the-legacy-mouse-pointer

15:42:28 [Patrick_H_Lauke]

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

15:43:23 [Patrick_H_Lauke]

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

15:43:40 [Patrick_H_Lauke]

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

15:44:30 [Patrick_H_Lauke]

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

15:44:55 [Patrick_H_Lauke]

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

15:45:40 [Patrick_H_Lauke]

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

15:48:29 [Patrick_H_Lauke]

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

15:48:49 [Patrick_H_Lauke]

Patrick: yes, we should just make that normative prose

15:49:01 [Patrick_H_Lauke]

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

15:49:23 [Patrick_H_Lauke]

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

15:50:12 [Patrick_H_Lauke]

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?

15:50:17 [Patrick_H_Lauke]

Mustaq: I can try yes

15:50:39 [Patrick_H_Lauke]

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

15:51:22 [Patrick_H_Lauke]

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

15:51:49 [Patrick_H_Lauke]

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

15:52:03 [Patrick_H_Lauke]

Olli: no movement

15:52:28 [Patrick_H_Lauke]

Mustaq: filed a bug, not heard back

15:52:40 [Patrick_H_Lauke]

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

15:53:00 [Patrick_H_Lauke]

TOPIC: Web Platform Tests

15:57:09 [Patrick_H_Lauke]

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 t

15:57:10 [Patrick_H_Lauke]

agged with "wpt" that will definitely *need* a new test for them, then we can go from there

15:57:46 [Patrick_H_Lauke]

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)

15:57:57 [Patrick_H_Lauke]

rrsagent, set logs world-visible

15:58:01 [Patrick_H_Lauke]

rrsagent, generate minutes

15:58:01 [RRSAgent]

I have made the request to generate https://www.w3.org/2022/08/17-pointerevents-minutes.html Patrick_H_Lauke

15:58:09 [Patrick_H_Lauke]

rrsagent, set logs world-visible

15:58:26 [Patrick_H_Lauke]

rrsagent, bye

15:58:26 [RRSAgent]

I see 4 open action items saved in https://www.w3.org/2022/08/17-pointerevents-actions.rdf :

15:58:26 [RRSAgent]

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

15:58:26 [RRSAgent]

recorded in https://www.w3.org/2022/08/17-pointerevents-irc#T15-49-01

15:58:26 [RRSAgent]

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 [2]

15:58:26 [RRSAgent]

recorded in https://www.w3.org/2022/08/17-pointerevents-irc#T15-49-23

15:58:26 [RRSAgent]

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

15:58:26 [RRSAgent]

recorded in https://www.w3.org/2022/08/17-pointerevents-irc#T15-50-39

15:58:26 [RRSAgent]

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) [4]

15:58:26 [RRSAgent]

recorded in https://www.w3.org/2022/08/17-pointerevents-irc#T15-57-46