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://
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://
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://
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