- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 26 May 2021 17:14:51 +0100
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Dear all, minutes from today's call are at https://www.w3.org/2021/05/26-pointerevents-minutes.html and copied below: PEWG 26 May 2021 Agenda: https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20210526T110000 Attendees Present flackr, mustaq, Patrick_h_Lauke, smaug Regrets - Chair: Patrick H. Lauke Scribe: Patrick_H_Lauke Contents * Review 'Simplify/clarify coalesced and predicted events' https://github.com/w3c/pointerevents/pull/377 * Do user agents only coalesce pointermove events relating to changes in position? https://github.com/w3c/pointerevents/issues/375 * It is unclear how predicted events' timestamps should relate to actual dispatched events https://github.com/w3c/pointerevents/issues/282 Meeting minutes Review 'Simplify/clarify coalesced and predicted events' https://github.com/w3c/pointerevents/pull/377 Flackr: (paraphrasing) we should focus on what author can expect, not saying what browser should do Olli: the reason we need the target change explicitly is for listeners that go from shadow dom to light dom, target will be different mustaq: but target gets defined at dispatch time Olli: this is what current spec says 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? [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] Olli: implementations return the same objects, which is why we need the retargeting Flackr: this is problematic Olli: this is not new, even for other types of events this is what happens (?) which is why we need to specify when target is changed Flackr: so target needs to be consistent with where the most recent event was dispatched Olli: technically could happen when it crosses the shadow boundary we need to specify at which point it happens mustaq: when calling next time looks better 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 Olli: think the PR doesn't change what spec says 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 [trying to find first appearance of target dirty] Patrick: https://github.com/w3c/pointerevents/pull/306 introduced this whole concept Flackr: what we just talked about is a change to what the spec currently says mustaq: so the spec needs to say this for developers (that retargeting happens when event crosses the boundary) Flackr: what the spec currently says is when it crosses boundary AND when the list is accessed <smaug> https://dom.spec.whatwg.org/#dispatching-events Patrick: anybody brave enough to update my PR to reflect all this? Flackr: happy to take that one ACTION: Flackr to update PR 377 further to include more specific info on retargeting 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 [landing to decision based on "trusted" events and whether these are special] Flackr: this is part of the same PR. "if the event is trusted, THEN change the target..." 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 mustaq: button state change is a tricky one [discussion that any non-discrete - like button state - changes can be coalesced, and spec should call this out] 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." as update to https://w3c.github.io/pointerevents/#coalesced-events mustaq: some devs may still not understand this, needs to define what non-discrete includes specifically Flackr: continuous may be clearer term? <mustaq> So the suggestion is: add a glossary definition for either discrete or non-discrete. ACTION: Patrick to draft a PR It is unclear how predicted events' timestamps should relate to actual dispatched events https://github.com/w3c/pointerevents/issues/282 [general agreement that this sounds good] Flackr: does user agent need to hallucinate future timestamps, or is it good enough to say it's the same as the current event needs a time prediction model Flackr: as long as we say they're monotonically increasing it doesn't matter to specify if they need to predict time or not ACTION: Patrick to make PR -- 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, 26 May 2021 16:15:06 UTC