Meeting minutes
<smaug> (just a sec)
trying to connect but failing, maybe i'm holding it wrong
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://
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://
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://
<mustaq> The second NOTE here defines canceling behavior of compat mouse events:
<mustaq> https://
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://
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://
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 t
agged 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)