- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 23 Jun 2021 17:12:34 +0100
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Dear all, minutes from today's call will be at https://www.w3.org/2021/06/23-pointerevents-minutes.html (though RRSAgent has been having issues) and copied below (apologies for the rough and ready manual formatting) Meeting: PEWG Chair: Patrick H. Lauke Agenda: https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20210623T110000 Scribe: Patrick H. Lauke Present: Olli Pettay Robert Flack Mustaq Ahmed Philippe Le Hégaret Patrick H. Lauke TOPIC: 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 present+ mustaq 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 ***RRSAgent records action 1 TOPIC: 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 ***RRSAgent records action 2 TOPIC: 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 ***RRSAgent records action 3 TOPIC: 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 ***RRSAgent records action 4 TOPIC: 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://github.com/w3c/pointerevents/issues/224 How is pointer event ctor supposed to work when coalescedEvents is passed using the PointerEventInit https://github.com/w3c/pointerevents/issues/223 Olli: I can try to write some PR ACTION: Olli to review/propose PRs for these ***RRSAgent records action 5 TOPIC: 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://w3c.github.io/pointerevents/#the-pointermove-event 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://w3c.github.io/pointerevents/#the-pointerrawupdate-event 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 ***RRSAgent records action 6 Patrick: thank you all, see you in two weeks' time P -- 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, 23 June 2021 16:12:59 UTC