- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 27 Apr 2022 16:52:14 +0100
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2022/04/27-pointerevents-minutes.html and copied below PEWG 27 April 2022 Agenda https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220427T110000 Attendees: flackr, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 * Clarify that coalesced events list contain also a clone of the parent event https://github.com/w3c/pointerevents/pull/436 * Defining event orders through a "state of the input device" https://github.com/w3c/pointerevents/issues/438 <smaug> now, let's see if webex has been fixed. <smaug> It didn't like some the user agents with >= 100 version number # Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 Patrick: I think last we looked at this, Olli wanted this to be verified on Google side Rob: on mobile, touch has implicit capture, which is why it fires the click... Olli: Chrome isn't consistent with itself between desktop and mobile. would prefer consistency, or if there's a good reason to explain the difference Rob: on mobile safari it seems that capture has not influenced the event stream at all Rob: we could consider this a bug. in the period before we generate click you can't have other events. click is sent async (because of double-tap to zoom), but i don't think you can get other pointer events until the UA has figured out if there's another click coming or not Rob: we could treat the current behaviour as bug, and say it should be delayed until the UA has resolved whether it's a click or not Olli: also option to change desktop chrome behavior to fire lostpointercapture after pointerup before click. that would bring consistency Rob: is the event target correct? Olli: that's separate bug #357 and this would solve it Rob: i believe target should be captured node until you release it Rob: sorry, that's current behavior, common ancestor Rob: fundamentals and dev expectations, two trains of thought: 1) you captured the event, you never released capture, you expect the click on the element where you captured Olli: so we postpone, and we also postpone click targeting Rob: it's dispatching to the common ancestor. suppose the click may not be retargeted. desktop chrome behavior is still doing the click target of the common ancestor Rob: but if you assume that click is fired while captured, should a captured click fire to the captured node rather than the common ancestor? Olli: yeah maybe that's you'd expect Olli: behavior that no browser has right now Olli: which might be fine since they're all doing different things right now Rob: it's different, and pointer capture not used on every page Olli: we had a moz-internal bug, but can't recall any other bugs about this issue. so maybe all web devs are using a library that handles all these cases, or maybe people aren't using it so much Patrick: i'm guessing from my own experience that devs may only be using it for simple things as it's a new concept. things like doing sliders and not having to attach/remove listeners to body anymore Olli: so to proceed. fire click on the captured target, and releasepointercapture after click Olli: and then look at getting browsers to implement Rob: especially as we consider click a pointer event, it makes sense for click to be captured Olli: maybe we can take a look at implementations, and see if we go with this approach if there are any more tricky edge cases, particularly on mobile Rob: should be doable, but will be complexity in making sure that we fire the capture release properly even if the click doesn't turn out to be a click (double-tap to zoom) Patrick: do we need to also say something about touch-action or is that implicit? Rob: implicit, don't need to mention. up to UA to know that a click can be processed right away if touch-action doesn't allow double-tap-to-zoom Olli: contextmenu ... [quick overview of when contextmenu is fired. after mouseup on windows, on mousedown on other platforms] Olli: if you capture pointer, and expect context menu, what happens? do you lose pointer capture? Rob: yes you should lose it Olli: what if you call preventDefault for contextmenu? Rob: then you shouldn't Rob: makes me wonder how a dev would handle right-click dragging Olli: would just preventDefault contextmenu and handle it as usual Patrick: would any of you like to make a stab at specifying? Olli: need to test first how feasible it is Rob: changing target on desktop shouldn't be a problem, mobile case / timing of releasing pointer capture will be trickier Olli: and see if the latter leads to some odd behaviors Patrick: suggest adding a comment on the issue to sum up what was discussed ACTION: explore feasibility of implementing proposed behavior from issue, think about possible edge cases that might arise # Clarify that coalesced events list contain also a clone of the parent event https://github.com/w3c/pointerevents/pull/436 Patrick: I dropped a super-naive comment on that, see if that makes any sense Rob: can't be a copy/clone because of potential resampling issue (e.g. different accuracy/rounding of coords) Rob: coalesced events list represents closest thing to raw events, parent event is the closest thing that the UA decides best represents that list of raw events Rob: rather than saying "all of the events that were coalesced into this event", should we say "list of all the events since the last event was dispatched", as that implies that it's inclusive Olli: and then need to say that parent event was generated based on that Patrick: so you'd never get an empty list (unless untrusted, because there it's up to dev) Rob: and then add a note in simple language for devs "what this means is that you either go by parent events, or coalesced events. don't mix and match/combine" [some wordsmithing/suggestion while looking at https://github.com/w3c/pointerevents/pull/436/files] Olli: we should also still say something about movement Rob: if you want i can try and have a go at this Olli: it should only be a couple of very short complicated sentences ACTION: Rob to make a new pull request to supersede #436 # Defining event orders through a "state of the input device" https://github.com/w3c/pointerevents/issues/438 Olli: is this mostly editorial? Patrick: looks like it wants to clarify what's implicit Rob: the diagram doesn't agree with my understanding of capture https://docs.google.com/presentation/d/1JZRsDN7fkHKlEv99tdMfpTe9G5LvARArfyX-EUHIwT0/edit#slide=id.g119142af639_0_0 Olli: wondering if this is needed for v3 or we can leave for after Rob: i think it's useful to define. difference between device that isn't *present*, and one that is just inactive (?) Rob: would be good to define this, helps explain what happens when an alert from the browser is fired etc Patrick: suggest asking mustaq to flesh this out some more. Rob if you don't mind adding comment on the issue about it not quite gelling with your understanding of capture. But yes if this turns out to open up a big pandora's box, we can always defer until after v3 is out ACTION: mustaq to propose some more fleshed out wording Patrick: thank you all, catch you again in 2 weeks' time -- 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, 27 April 2022 15:52:28 UTC