Meeting minutes
Review 'Expand explanation for non-coalesced events' https://github.com/w3c/pointerevents/pull/379 (in particular, use of "measurable" in the definition)
Patrick: [explains the conundrum we had with continuous/discrete / measurable/countable, etc]
Olli: concern about including/listing UI-Events ... are there more properties?
Rob: reason why i didn't want to list all properties, what if things change or other specs add more properties
Olli: think PR is quite close though
Rob: will see if there are suggestions to make on this
Mustaq: would also remove shiftkey/altkey/metakey as they don't fire pointer events at all
Rob: maybe we can even give the example about button not being continuous as the value just changes, you don't get the "in-between" values
Patrick: might be getting too deep into weeds of buttons which is not even our spec
Action: review this PR for next meeting and suggest changes by then
Review 'task queue is not reliable HTML concept. Use event loop instead' https://github.com/w3c/pointerevents/pull/386
PLH: we are getting better at referencing, but other specs can tell when WE do bad referencing. task queue not reliable concept, so should use event loop
Patrick: defer to other people who are more knowledgeable
Olli: it's ... ok
Olli: technically you put a task into the queue...
Mustaq: the spec does handwave saying that "queue is not a queue"
PLH: we rely on DOM to fire event, so we don't have to say anything about when/how to fire
Patrick: so we happy to merge this?
[no concerns]
Action: merge and close
Review 'Simplify/clarify coalesced and predicted events' https://github.com/w3c/pointerevents/pull/377
Rob: I should have more time soon, so can look at this for next meeting
Patrick: if anybody else also has any ideas, jump in. the PR is mostly ok, the last sticking point was the need to go into the targeting/retargeting (my PR was a bit too brutal in removing it altogether)
Action: Rob to review this PR and add suggested wording for the targeting issue
Unclear note about PointerEvent initialization of attributes to reflect coalesced events https://github.com/w3c/pointerevents/issues/374
Rob: high-level purpose here is that developers don't need to care about the individual (non-coalesced) events, but just look at the fired events
Patrick: but is this going into the weeds of sometihng we don't want to define/that they shouldn't care?
Rob: this is just to reinforce/give an example
Rob: implementation shouldn't need to do this, but this is only an example
Patrick: any value in me having a stab at generalising this, without having to give a specific example?
Rob: movement is a good example though - it's a delta from the last change
Mustaq: we could say this without mentioning pointerlock
Rob: yes this is true even without pointerlock
Patrick: I might give a try proposing a slightly more generalised wording, without mentioning pointerlock, that achieves same
Action: Patrick to propose more generalised wording for the note
The behavior of getCoalescedEvent in pointerevent_constructor.html is inconsistent with the spec https://github.com/w3c/pointerevents/issues/229
Patrick: is this going to be resolved by the work Rob is going to do on the PR?
Rob: we were going to say this is true for trusted events
Olli: will review this and the other related issues
"This API always returns at least one coalesced event for pointermove events and an empty list for other types of PointerEvents." https://
How is pointer event ctor supposed to work when coalescedEvents is passed using the PointerEventInit https://
Olli: I can try to write some PR
Action: Olli to review/propose PRs for these
HTML monkeypatching: initiate the drag-and-drop operation definition https://github.com/w3c/pointerevents/issues/384 and HTML monkeypatching: animation frame callbacks https://github.com/w3c/pointerevents/issues/385
Patrick: Starting with the drag and drop one #384
Olli: we should do this, but think it's still not possible to write platform test for d'n'd. at least wasn't last time
PLH: you agree we should add the spec the requirement to fire pointercancel etc?
Olli: that or add a hook
PLH: they declined to add a hook. asked for it to be exported
PLH: should i make a stab at this?
Olli: i don't have time for this right now
Mustaq: I can take a look
Patrick: you're it mustaq, assigned you. next up animation frame monkeypatching
Olli: ... it's about scheduling of tasks, and that's not defined anywhere. HTML spec lets you schedule tasks any way you want. maybe we should clarify somehow in PE spec, not sure how
PLH: domenic suggested adding a new function to fire pointer event
Olli: it's not even about pointer events...
Rob: it also doesn't have any well defined time WHEN you want to fire, you may want to do it before or after, depending on performance etc
Olli: implementations will likely change over time
Rob: we could say it should happen at some point between two points - producing a frame
Olli: even that could be not true / browser may choose to paint more and listen to events less, depending on priority. would prefer having plenty of flexibility
Patrick: i think it's a "soft" *may* we use in that sentence in the spec
https://
Rob: only thing we can guarantee is that events will be dispatched in order
we would flush coalesced events before next fired event
PLH: we could remove the sentence altogether as we already say things in the specific coalesced events section
PLH: suggest either removing the sentence, or moving it to the section for coalesced. and we don't mention animation callbacks
<mustaq> https://
Mustaq: there's also mention of animation (without link) in the pointerraw
Patrick: could we just change "which might be aligned to animation callbacks" to "which might be delayed"
Rob: we just need to say that raw events will not be delayed
Action: Patrick to write PR that removes the referenced animation frame callback sentence altogether and removes mention in pointerraw
Patrick: thank you all, see you in two weeks' time
hmm...seems to take a long time to generate these minutes. is the functionality working?