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