Meeting minutes
present_ mustaq
Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445
Patrick: we have 5 open https://
Olli: i did file the webdriver issue about coalesced/predicted events
Olli: but will still need to be manual for now, as it won't be supported anytime soon
Mustaq: fixed some of the test, hope to do 411 after TPAC
consider to change the behavior of getCoalescedEvents on non-SecureContext w3c/pointerevents#472
Patrick: I made a naive minimal PR, can we check it? https://
Olli: before that, do we have data from the use counter?
Mustaq: we've not looked into this...
Rob: the use counter was added in juli
Mustaq: but since, we looked at the counter and there was no data, so might not have been used
<flackr> https://
Rob: but it's relatively new counter, so may not be representative
Olli: if usage is very low, we could try to keep spec as it is right now...
Rob: i think this is low enough for us to consider NOT to have the API
Olli: so Patrick we don't need your PR at all
Patrick: so do we need to say anything in spec about it only being for secure context?
Rob: no, it already says so in the IDL
RESOLUTION: PR not needed
Patrick: can we close w3c/
Olli: one other issue already has needs-WPT, so don't need to keep this one open
<smaug> w3c/
Clarify pointerleave and pointerout events when first pointer move after removing an element under the pointer w3c/pointerevents#477
Rob: there's a discussion on the interop
<mustaq> web-platform-tests/
Olli: i was looking at it too, and your proposal seemed reasonable ... but there are issues: if you change slot attribute, you end up being slotted elsewhere, so it's almost like a removal...what should happen then, since ancestor chain will be different
Rob: we should track the nearest non-removed ancestor of the event path
Olli: not when you're changing node, but when you change slot
Rob: does that not fire change as well?
Rob: I think we should interpret it as: that entire slot was removed, so the node that the mouse was previously over that had enter fired to it...
Olli: nothing would be removed from the DOM, so we need to fire something else... the flatten tree is different because the slot is different ... need to think about this a bit more. but liked your idea
Mustaq: can we add note in issue?
Mustaq: added a few points in the interop issue
Mustaq: the test currently assumes that in and out events are interleaved on the parent node
Rob: we should test the case where the cursor is STILL over the same parent, so doesn't need to fire another enter
Rob: there are more cases that need to be tested
Mustaq: another question about event order (does over come before enter, etc). PE doesn't specify it...
Rob: we should match UI Events order
Mustaq: problem is UI Events doesn't define this either (?)
Mustaq: only WPTs that assert it
Rob: we should file an issue to specify which one fires first
Rob: suspect enter should fire before over, because we don't dispatch enter to ancestors, but over we do
Mustaq: because over bubbles, but enter doesn't
Olli: I think over is dispatched first...
[further discussion on current weird order in different implementations]
Rob: as developer, i'd expect enter - over and then out - leave
Olli: but as developer you wouldn't listen to both in most cases
Rob: we currently fire over then enter, and out then leave ... which is weird
Rob: test for mouse seems to pass in all browsers. think it's wrong, but not going to argue too strongly that we should change it
Mustaq: checking the mouse one ... over then enter, out then leave ... and that's been there forever
Mustaq: so keep this assumption for our own WPTs?
Rob: how hard would it be to change it (for mouse events as well?). might add a use counter
<mustaq> https://
Olli: this is defined in a sense in UI Events 5.3.3
Rob: don't like the order, but no reason why PE shouldn't do the same thing
<mustaq> The order specified by example there is (over, enter, out, leave).
<mustaq> Let's keep that in the current test then
Rob: not specified in PE, and maybe PE should say something about it...
Rob: should have the same event ordering as mouse events, explicitly
ACTION: consider if PE needs to clarify event order for enter/over leave/out etc
ACTION: Rob to consider if PE needs to clarify event order for enter/over and leave/out etc
video for TPAC
Patrick: I've got the presentation ready with links to various demos that we want to show, have carved out time to record it tomorrow and send it, will then be on the w3c site before TPAC (will share link once I have it)