13:56:33 <RRSAgent> RRSAgent has joined #pointerevents
13:56:33 <RRSAgent> logging to https://www.w3.org/2022/04/27-pointerevents-irc
14:40:38 <Patrick_H_Lauke> Meeting: PEWG
14:40:43 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:40:49 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220427T110000
14:41:01 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:41:07 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
14:41:13 <Patrick_H_Lauke> present+ Patrick_H_Lauke
14:58:27 <smaug> now, let's see if webex has been fixed.
14:58:47 <smaug> It didn't like all the user agents with >= 100 version number
14:59:55 <smaug> s/all/some/
15:00:31 <flackr> flackr has joined #pointerevents
15:02:35 <Patrick_H_Lauke> present+ smaug
15:02:43 <Patrick_H_Lauke> present+ flackr
15:02:58 <Patrick_H_Lauke> TOPIC: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356
15:03:47 <Patrick_H_Lauke> Patrick: I think last we looked at this, Olli wanted this to be verified on Google side
15:04:09 <Patrick_H_Lauke> Rob: on mobile, touch has implicit capture, which is why it fires the click...
15:05:35 <Patrick_H_Lauke> 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
15:07:18 <Patrick_H_Lauke> Rob: on mobile safari it seems that capture has not influenced the event stream at all
15:08:54 <Patrick_H_Lauke> 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
15:09:21 <Patrick_H_Lauke> 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
15:09:49 <Patrick_H_Lauke> Olli: also option to change desktop chrome behavior to fire lostpointercapture after pointerup before click. that would bring consistency
15:10:03 <Patrick_H_Lauke> Rob: is the event target correct?
15:10:18 <Patrick_H_Lauke> Olli: that's separate bug #357 and this would solve it
15:10:37 <Patrick_H_Lauke> Rob: i believe target should be captured node until you release it
15:11:29 <Patrick_H_Lauke> Rob: sorry, that's current behavior, common ancestor
15:13:29 <Patrick_H_Lauke> 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
15:13:40 <Patrick_H_Lauke> Olli: so we postpone, and we also postpone click targeting
15:14:14 <Patrick_H_Lauke> 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
15:14:39 <Patrick_H_Lauke> 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?
15:14:45 <Patrick_H_Lauke> Olli: yeah maybe that's you'd expect
15:14:58 <Patrick_H_Lauke> Olli: behavior that no browser has right now
15:15:11 <Patrick_H_Lauke> Olli: which might be fine since they're all doing different things right now
15:15:27 <Patrick_H_Lauke> Rob: it's different, and pointer capture not used on every page
15:16:14 <Patrick_H_Lauke> 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
15:17:50 <Patrick_H_Lauke> 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
15:18:30 <Patrick_H_Lauke> Olli: so to proceed. fire click on the captured target, and releasepointercapture after click
15:18:53 <Patrick_H_Lauke> Olli: and then look at getting browsers to implement
15:19:10 <Patrick_H_Lauke> Rob: especially as we consider click a pointer event, it makes sense for click to be captured
15:19:47 <Patrick_H_Lauke> 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
15:20:28 <Patrick_H_Lauke> 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)
15:21:41 <Patrick_H_Lauke> Patrick: do we need to also say something about touch-action or is that implicit?
15:22:09 <Patrick_H_Lauke> 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
15:22:41 <Patrick_H_Lauke> Olli: contextmenu ...
15:23:00 <Patrick_H_Lauke> [quick overview of when contextmenu is fired. after mouseup on windows, on mousedown on other platforms]
15:23:26 <Patrick_H_Lauke> Olli: if you capture pointer, and expect context menu, what happens? do you lose pointer capture?
15:23:31 <Patrick_H_Lauke> Rob: yes you should lose it
15:23:59 <Patrick_H_Lauke> Olli: what if you call preventDefault for contextmenu?
15:24:15 <Patrick_H_Lauke> Rob: then you shouldn't
15:24:48 <Patrick_H_Lauke> Rob: makes me wonder how a dev would handle right-click dragging
15:25:02 <Patrick_H_Lauke> Olli: would just preventDefault contextmenu and handle it as usual
15:25:40 <Patrick_H_Lauke> Patrick: would any of you like to make a stab at specifying?
15:25:48 <Patrick_H_Lauke> Olli: need to test first how feasible it is
15:26:05 <Patrick_H_Lauke> Rob: changing target on desktop shouldn't be a problem, mobile case / timing of releasing pointer capture will be trickier
15:26:16 <Patrick_H_Lauke> Olli: and see if the latter leads to some odd behaviors
15:27:10 <Patrick_H_Lauke> Patrick: suggest adding a comment on the issue to sum up what was discussed
15:27:40 <Patrick_H_Lauke> ACTION: explore feasibility of implementing proposed behavior from issue, think about possible edge cases that might arise
15:28:07 <Patrick_H_Lauke> TOPIC: Clarify that coalesced events list contain also a clone of the parent event https://github.com/w3c/pointerevents/pull/436
15:28:30 <Patrick_H_Lauke> Patrick: I dropped a super-naive comment on that, see if that makes any sense
15:30:20 <Patrick_H_Lauke> Rob: can't be a copy/clone because of potential resampling issue (e.g. different accuracy/rounding of coords)
15:30:51 <Patrick_H_Lauke> 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
15:31:56 <Patrick_H_Lauke> 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
15:32:13 <Patrick_H_Lauke> Olli: and then need to say that parent event was generated based on that
15:33:01 <Patrick_H_Lauke> Patrick: so you'd never get an empty list (unless untrusted, because there it's up to dev)
15:33:39 <Patrick_H_Lauke> 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"
15:37:44 <Patrick_H_Lauke> [some wordsmithing/suggestion while looking at https://github.com/w3c/pointerevents/pull/436/files]
15:37:58 <Patrick_H_Lauke> Olli: we should also still say something about movement
15:38:12 <Patrick_H_Lauke> Rob: if you want i can try and have a go at this
15:38:25 <Patrick_H_Lauke> Olli: it should only be a couple of very short complicated sentences
15:39:41 <Patrick_H_Lauke> ACTION: Rob to make a new pull request to supersede #436
15:40:58 <Patrick_H_Lauke> TOPIC: Defining event orders through a "state of the input device" https://github.com/w3c/pointerevents/issues/438
15:42:53 <Patrick_H_Lauke> Olli: is this mostly editorial?
15:43:02 <Patrick_H_Lauke> Patrick: looks like it wants to clarify what's implicit
15:43:18 <Patrick_H_Lauke> 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
15:44:23 <Patrick_H_Lauke> Olli: wondering if this is needed for v3 or we can leave for after
15:45:11 <Patrick_H_Lauke> Rob: i think it's useful to define. difference between device that isn't *present*, and one that is just inactive (?)
15:45:36 <Patrick_H_Lauke> Rob: would be good to define this, helps explain what happens when an alert from the browser is fired etc
15:47:08 <Patrick_H_Lauke> 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
15:48:06 <Patrick_H_Lauke> ACTION: mustaq to propose some more fleshed out wording
15:48:17 <Patrick_H_Lauke> Patrick: thank you all, catch you again in 2 weeks' time
15:48:24 <Patrick_H_Lauke> RRSAgent, set logs world-visible
15:48:34 <Patrick_H_Lauke> rrsagent, make minutes
15:48:34 <RRSAgent> I have made the request to generate https://www.w3.org/2022/04/27-pointerevents-minutes.html Patrick_H_Lauke
15:48:41 <Patrick_H_Lauke> rrsagent, set logs world-visible
15:48:51 <Patrick_H_Lauke> rrsagent, bye
15:48:51 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2022/04/27-pointerevents-actions.rdf :
15:48:51 <RRSAgent> ACTION: explore feasibility of implementing proposed behavior from issue, think about possible edge cases that might arise [1]
15:48:51 <RRSAgent>   recorded in https://www.w3.org/2022/04/27-pointerevents-irc#T15-27-40
15:48:51 <RRSAgent> ACTION: Rob to make a new pull request to supersede #436 [2]
15:48:51 <RRSAgent>   recorded in https://www.w3.org/2022/04/27-pointerevents-irc#T15-39-41
15:48:51 <RRSAgent> ACTION: mustaq to propose some more fleshed out wording [3]
15:48:51 <RRSAgent>   recorded in https://www.w3.org/2022/04/27-pointerevents-irc#T15-48-06