15:03:13 <RRSAgent> RRSAgent has joined #pointerevents
15:03:13 <RRSAgent> logging to https://www.w3.org/2021/05/26-pointerevents-irc
15:03:40 <Patrick_H_Lauke> Meeting: PEWG
15:03:44 <Patrick_H_Lauke> Chair: Patrick H. Lauke
15:04:06 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20210526T110000
15:04:24 <Patrick_H_Lauke> Scribe: Patrick_H_Lauke
15:04:37 <Patrick_H_Lauke> present+ smaug
15:04:45 <Patrick_H_Lauke> present+ flackr
15:04:51 <Patrick_H_Lauke> present+ mustaq
15:04:56 <Patrick_H_Lauke> present+ Patrick_h_Lauke
15:05:33 <Patrick_H_Lauke> Topic: Review 'Simplify/clarify coalesced and predicted events' https://github.com/w3c/pointerevents/pull/377
15:08:34 <Patrick_H_Lauke> Flackr: (paraphrasing) we should focus on what author can expect, not saying what browser should do
15:09:24 <Patrick_H_Lauke> Olli: the reason we need the target change explicitly is for listeners that go from shadow dom to light dom, target will be different
15:09:47 <Patrick_H_Lauke> mustaq: but target gets defined at dispatch time
15:09:57 <Patrick_H_Lauke> Olli: this is what current spec says
15:16:03 <Patrick_H_Lauke> Patrick: if the scenario is about an event bubbling from shadow to light, as an author if i have a listener in both, don't i just need to know that wherever my listener was, that's the target of where the listener was?
15:16:35 <Patrick_H_Lauke> [discussion on whether the list is live, but event objects are the same, and how this would lead to leaking access from shadow to light dom]
15:17:25 <Patrick_H_Lauke> Olli: implementations return the same objects, which is why we need the retargeting
15:17:31 <Patrick_H_Lauke> Flackr: this is problematic
15:17:45 <Patrick_H_Lauke> Olli: this is not new, even for other types of events this is what happens (?)
15:18:00 <Patrick_H_Lauke> which is why we need to specify when target is changed
15:18:27 <Patrick_H_Lauke> Flackr: so target needs to be consistent with where the most recent event was dispatched
15:18:46 <Patrick_H_Lauke> Olli: technically could happen when it crosses the shadow boundary
15:19:20 <Patrick_H_Lauke> we need to specify at which point it happens
15:19:38 <Patrick_H_Lauke> mustaq: when calling next time looks better
15:22:23 <Patrick_H_Lauke> Flackr: this could be done efficiently ... if events know that they'll be coalesced, the can just refer to their parent event to know what the target is
15:23:29 <Patrick_H_Lauke> Olli: think the PR doesn't change what spec says
15:24:05 <Patrick_H_Lauke> Flackr: i think most developer friendly way would be to change target when it crosses boundary, not having to wait for when getCoalescedEvents is called
15:30:26 <Patrick_H_Lauke> [trying to find first appearance of target dirty]
15:30:33 <Patrick_H_Lauke> Patrick: https://github.com/w3c/pointerevents/pull/306 introduced this whole concept
15:31:51 <Patrick_H_Lauke> Flackr: what we just talked about is a change to what the spec currently says
15:32:15 <Patrick_H_Lauke> mustaq: so the spec needs to say this for developers (that retargeting happens when event crosses the boundary)
15:32:40 <Patrick_H_Lauke> Flackr: what the spec currently says is when it crosses boundary AND when the list is accessed
15:32:56 <smaug> https://dom.spec.whatwg.org/#dispatching-events
15:35:34 <Patrick_H_Lauke> Patrick: anybody brave enough to update my PR to reflect all this?
15:35:41 <Patrick_H_Lauke> Flackr: happy to take that one
15:36:14 <Patrick_H_Lauke> ACTION: Flackr to update PR 377 further to include more specific info on retargeting
15:38:06 <Patrick_H_Lauke> Olli: then we need to think about what happens with JS created events, when developer wants to add random other events that were already dispatched
15:38:25 <Patrick_H_Lauke> [landing to decision based on "trusted" events and whether these are special]
15:39:19 <Patrick_H_Lauke> Flackr: this is part of the same PR. "if the event is trusted, THEN change the target..."
15:42:16 <Patrick_H_Lauke> TOPIC: Do user agents only coalesce pointermove events relating to changes in position? https://github.com/w3c/pointerevents/issues/375Unclear note about PointerEvent initialization of attributes to reflect coalesced events
15:43:57 <Patrick_H_Lauke> mustaq: button state change is a tricky one
15:47:30 <Patrick_H_Lauke> [discussion that any non-discrete - like button state - changes can be coalesced, and spec should call this out]
15:50:46 <Patrick_H_Lauke> Patrick: is the term discrete/non-discrete common/accurate enough to propose some simple wording change (easy for layperson as well) a la "not to send a pointermove event every time a non-discrete property (such as coordinates, pressure, tangential pressure, tilt, twist, or contact geometry) of a pointer is updated."
15:51:23 <Patrick_H_Lauke> as update to https://w3c.github.io/pointerevents/#coalesced-events
15:54:10 <Patrick_H_Lauke> mustaq: some devs may still not understand this, needs to define what non-discrete includes specifically
15:54:30 <Patrick_H_Lauke> Flackr: continuous may be clearer term?
15:55:12 <mustaq> So the suggestion is: add a glossary definition for either discrete or non-discrete.
15:56:44 <Patrick_H_Lauke> ACTION: Patrick to draft a PR
15:56:47 <Patrick_H_Lauke> TOPIC: It is unclear how predicted events' timestamps should relate to actual dispatched events https://github.com/w3c/pointerevents/issues/282
15:58:47 <Patrick_H_Lauke> [general agreement that this sounds good]
15:59:36 <Patrick_H_Lauke> Flackr: does user agent need to hallucinate future timestamps, or is it good enough to say it's the same as the current event
15:59:53 <Patrick_H_Lauke> needs a time prediction model
16:00:12 <bkardell_> bkardell_ has joined #pointerevents
16:01:24 <Patrick_H_Lauke> Flackr: as long as we say they're monotonically increasing it doesn't matter to specify if they need to predict time or not
16:01:56 <Patrick_H_Lauke> ACTION: Patrick to make PR
16:02:39 <Patrick_H_Lauke> rrsagent, set logs world-visible
16:02:52 <Patrick_H_Lauke> rrsagent, create minutes
16:02:52 <RRSAgent> I have made the request to generate https://www.w3.org/2021/05/26-pointerevents-minutes.html Patrick_H_Lauke
16:05:17 <Patrick_H_Lauke> rrsagent, bye
16:05:17 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2021/05/26-pointerevents-actions.rdf :
16:05:17 <RRSAgent> ACTION: Flackr to update PR 377 further to include more specific info on retargeting [1]
16:05:17 <RRSAgent>   recorded in https://www.w3.org/2021/05/26-pointerevents-irc#T15-36-14
16:05:17 <RRSAgent> ACTION: Patrick to draft a PR [2]
16:05:17 <RRSAgent>   recorded in https://www.w3.org/2021/05/26-pointerevents-irc#T15-56-44
16:05:17 <RRSAgent> ACTION: Patrick to make PR [3]
16:05:17 <RRSAgent>   recorded in https://www.w3.org/2021/05/26-pointerevents-irc#T16-01-56