- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 7 Jun 2023 17:29:18 +0100
- To: public-pointer-events@w3.org
Dear all, the minutes from today's meeting are at https://www.w3.org/2023/06/07-pointerevents-minutes.html and copied below: PEWG 07 June 2023 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20230607T110000 Attendees: flackr, Mustaq, Patrick_H_Lauke, 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 * Heartbeat: Clarify what the target of the click event should be after capturing pointer events w3c/pointerevents#356 * spec doesn't match WPTs #303 hmmm...can't seem to start the meeting in zoom i mean <smaug> ah, you're not the host? suspect it's because Philippe is still the host <mustaq> I am seeing "Waiting for host to start the meeting" <flackr> should we use an alternative for today? ok, quick change of plan...firing up a separate zoom. please hold snap https://us02web.zoom.us/j/9880060302?pwd=Rmk1MUV2b253RE9tVnBJUkZJZ2QzUT09 # Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445 Go over https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+ Patrick: so how are we doing with the WPTs? Olli: it's going down. think it was 10-11 last time Olli: I closed one, Edgar closed one Mustaq: I closed one, and have one waiting for review Olli: added a comment to the one about secure context Olli: that's something we probably need to change. would be risky right now to hide the whole method, instead we could always expose the same event as the real event <mustaq> w3c/pointerevents#318 Mustaq: agree it's risky, don't think we have a counter. not sure how many sites rely on this. probably just returning empty list would be ok Olli: not thinking empty list, it should always have one, so just send a copy of the same parent event Olli: so we'd need to change the spec a tiny bit Olli: worried some libraries might already rely on this, but don't have any data. Mustaq: think we can go for it Olli: issue filed for this here w3c/pointerevents#472 Rob: wouldn't want to change things until we have data Rob: APIs have been around for a long time, so best to wait for data Olli: what i'm suggesting would not break API though, it just returns a single item list Mustaq: if we can count how many times getCoalescedEvent gets called in a non-secure context, we can switch it over Rob: if we had the data to suggest that this isn't being used from non-secure context, we should remove the method. would be less surprising Olli: but if the API doesn't break, just that it only returns a single item... [discussion on whether we want to wait for data or not] Patrick: i'd suggest going for the "simpler" approach that Olli suggested - keep method/API, but clarify that the list only contains a single CLONE of the parent event Patrick: but also gather data, then we can in future think about removing the method altogether in non-secure context if data shows that nobody's using it in those cases ACTION: Patrick to look at #472 and propose PR to clarify what happens in non-secure contexts (only returns a list with single item, CLONE of parent) Olli: was also trying to look at w3c/pointerevents#390 ... Mustaq: I landed a change, by end of today you should be able to test it <mustaq> It is an automated test now. Patrick: so let's carry on with this. will send reminder a week before next meeting # Heartbeat: Clarify what the target of the click event should be after capturing pointer events w3c/pointerevents#356 Patrick: since last meeting, I spent some time visually highlighting the outlier results in w3c/pointerevents#356 (comment) ... now clearer to see where the differences in click are, but there's also a very weird outlier in Safari/iOS for the second scenario, which does look more like a bug at their end than something Safari team explicitly did, since Safari/macOS doesn't have this[CUT] either [looking at what we decided last time] Patrick: minutes from last time https://www.w3.org/2023/05/24-pointerevents-minutes.html [more discussion on what we went over previously] Mustaq: ... most recent discussion was about async click... Patrick: minutes from two meetings ago has more of our thinking at the time https://www.w3.org/2023/05/10-pointerevents-minutes.html Rob: ...click event is not meant to be separately targeted, so should not be different from the up event... do the computation of what click target should be at the point where we do the up event... Mustaq: challenge is that lostpointercapture has been fired, but then forcing click to go to what was captured before (and click going to blue) Olli: ...what happens to the mouseup - i know it's legacy, but still used... Olli: what is the target of that if pointerup explicitly releases Mustaq: with mouse it's easier, because everything is synchronous Olli: just wondering what the behaviour here should be though Olli: may also need to add mousedown/mouseup, as some of the behaviour we see may be related to these legacy events Rob: also don't want to forget what author/developer expectation would be when using pointer capture Patrick: i guess as developer, i wouldn't care about where the mouseup happens if i'm capturing... but i think what we're getting at is that the need to create legacy mouse events MAY be the root cause of this weirdness, since we didn't spec it so precisely ourselves. ACTION: Extend the test codepen to also include mousedown/mouseup, rerun results ACTION: before next meeting, will send email reminding everybody to COME PREPARED with their own take of what the best/most reasonable way forward here is Rob: related, do we know of any major sites using pointer capture? Patrick: I often feel no real-world developer out there is making heavy use of pointerevents, though now pleased to see sessions from latest Apple event consistently now using pointerevents Mustaq: I have vague memories of some side-scrolling game using it... Rob: more interesting then as well - how many sites are using capture AND are then hot-swapping the element that has capture, i guess not many Rob: let's do a detailed session next time about this <mustaq> w3c/pointerevents#303 # spec doesn't match WPTs #303 Mustaq: railing behaviour in WPT - once scroll starts, Chrome tries to latch onto that direction... Mustaq: [explains current behaviour in Chrome, which passes the WPT, but all other browsers fail?] [discussion on what current behaviour in Chrome is...that the browser can take over in the course of an ongoing gesture] Mustaq: the test was done a long time ago, legacy behaviour Patrick: i'd say most sensible would be to change the test and Chrome's legacy behaviour, and make sure our spec is clear about ONGOING gestures Rob: [mentions the "slop" and the point at which a developer could safely assume whether the browser is scrolling or if they now have control over that gesture] Mustaq: at some point (?) we had the philosophy that browser could take over at any point even for ongoing gestures Mustaq: definition of "slop" is not in the spec Rob: but it's developer-observable. move fires at the point where you exceed the slop region Olli: do you happen to have a test case for all this (not necessarily WPT, just anywhere) Mustaq: we have quite a few tests in WPT Rob: you can look at the cancelable flag on the move event, and you can tell from that whether it started to scroll Rob: once we start a scroll it's no longer cancelable Olli: spec says pointermove is always cancelable <mustaq> https://w3c.github.io/pointerevents/#attributes-and-default-actions Patrick: but no pointermoves are sent when scrolling starts Rob: but on that last event before it scrolls... Rob: how can dev tell in their pointer handler that browser took over scrolling [more discussion] Rob: going back to initial issue, we should make sure that only initial direction is used, and browser does not decide during an ongoing gesture to jump back in and take over scrolling Patrick: agree, change WPT accordingly, make sure spec is explicit about it, and then change chrome behaviour Rob: do we know any sites that rely on this particular behaviour, if it only happens in Chrome ACTION: test #303 not in webdriver (which has potential bugs), but in real browser Rob: one more point against current behaviour is the asymmetry of the behaviour... -- 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, 7 June 2023 16:29:28 UTC