Meeting minutes
<smaug> https://
Status of WG charter
plh: has been sent for review, deadline end of June. should be smooth, people will remain in the WG, purely administrative at the moment
plh: as soon as we incubated an explainer for gestures, we can recharter - we won't have to wait for 2 years though
plh: we can make room in this WG to incubate
PE Level 3 status
plh: also under AC review, sent it after extending group charter. once we have new charter, we can forget about PE 3. i will then remove PE 2
plh: and next time we'll be more strict about PE 4 shipping ... unlike PE 3 that got stuck for a long time trying to finalise one last feature
plh: thank you all for your work on the tests/test results
Broken links in Pointer Events #641 w3c/pointerevents#641
plh: this got fixed by itself when we republished PE3. can be closed
patrick: done
action from last meeting Patrick to file an issue on PE about removing reliance on/reference to remaining UI events, we can flesh out further
patrick: gave myself a task to file an issue. not looked in depth but specific issue is here w3c/
patrick: wondering if we can firm things up a bit ... like the move of keyboard event potentially to editing WG
plh: timing is unfortunate for us to do it, as it's not in charter
ACTION: plh to look into talking to editing WG to take over keyboard part of UI events
plh: fundamentally not a PE issue though
patrick: yes, it's just that we stripped UI events for parts for what we need, so the remaining bit is keyboard so this is more a courtesy for editing WG to deal with taking over the orphaned remains
action from last time mustaq to look at moving/removing references to UI events related to pointerlock spec
mustaq: didn't have time, can look at it soon
plh: if you need help, let me know
plh: i can make PR for pointerlock
ACTION: plh to move pointerlock-related parts of UI events to pointerlock
Any "MouseEvent" issues that need to be prioritised? https://github.com/w3c/pointerevents/issues?q=is%3Aissue%20state%3Aopen%20label%3AMouseEvent
patrick: happy to do it async, or we do it now
plh: editorial: we need to harmonise in our spec how we present events. currently there's a mix of styles
patrick: i'll look at this, report back next time
ACTION: Patrick to look at harmonising how events are presented (old UI events style and our own legacy way)
plh: should prioritise mouse events and pointer events in terms of initialisation
flackr: one thing we were missing originally was an authoritative target. ui events was handwavy there, and we had trouble piggy-backing on that. now that we took ownership, we control the dispatch algo
ACTION: flackr to look at any duplication we now have about event dispatch/initialisation
mustaq: the handwavy prose about out and in events and how they're fired
<mustaq> Old handwavy mouse boundary event "spec": https://
plh: dispatch first, then initialisation. once clarified those, then we can move event by event to make sure they're consistent. and then hit testing, because it's super easy /s
<flackr> https://
plh: do we need to look at event order?
flackr: the mouse-related order is still valid, but then the question about when exactly they interleave
patrick: because originally in PE we were quite handwavy about the order you MIGHT get
flackr: now the dispatch should also care about pointer capture, which will be nice
TPAC
patrick: when's the deadline for TPAC?
plh: deadline 17 June. who's going?
Patrick: I am
Olli: I am
(others unlikely)
plh: we don't necessarily need our own meeting slot. can always ask other chairs if they want somebody from PE and we can go into their meetings
Group decided not to have a specific meeting slot, but for those there happy to join other groups on request
Olli: so should we go async through the existing issues in https://
plh: yes, and then move to initialisation
<smaug> Tiny bit related to dispatch. https://