- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 30 Aug 2023 16:41:23 +0100
- To: public-pointer-events@w3.org
Dear all, the minutes from today's meeting are at https://www.w3.org/2023/08/30-pointerevents-minutes.html and copied below: PEWG 30 August 2023 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20230830T110000/ Attendees flackr, mustaq, Patrick_H_Lauke, plh, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445 * consider to change the behavior of getCoalescedEvents on non-SecureContext w3c/pointerevents#472 * Clarify pointerleave and pointerout events when first pointer move after removing an element under the pointer w3c/pointerevents#477 * video for TPAC # Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445 Patrick: we have 5 open https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+ 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 w3c/webdriver#1759 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://github.com/w3c/pointerevents/pull/480/files 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://chromestatus.com/metrics/feature/timeline/popularity/4598 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/pointerevents#472 ? Olli: one other issue already has needs-WPT, so don't need to keep this one open <smaug> w3c/pointerevents#318 has needs-wpt, and I'll write a test # 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/interop#380 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://www.w3.org/TR/uievents/#events-mouseevent-event-order 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) -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 30 August 2023 15:41:34 UTC