- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 17 Aug 2022 17:06:23 +0100
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Dear all, the minutes from today's brief meeting are at https://www.w3.org/2022/08/17-pointerevents-minutes.html and copied below: PEWG 17 August 2022 Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220817T110000 Attendees: 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?] <mustaq> https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events 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 behaviour) Rob: for ordering (within pointer) we should defer to UI events and x-reference 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... Patrick: https://w3c.github.io/pointerevents/#mapping-for-devices-that-support-hover <mustaq> The second NOTE here defines canceling behavior of compat mouse events: <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 <flackr> https://w3c.github.io/pointerevents/#tracking-the-effective-position-of-the-legacy-mouse-pointer 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