Meeting minutes
harmonising how events are presented (old UI events style and our own legacy way)
plh: reminder that next week will be the deadline for AC review of charter and PE3 to REC. poke your rep if they haven't voted already
Patrick: i've been looking at how pointerevents has been listing/explaining the interfaces and events. we use dictionary and event interface with the IDL, and for each individual event (like pointerdown) we then just use prose. in mouse events and wheel events it splits the interface and the init dictionary, and for each event it provides a whole table. which one do we prefer/want?
mustaq: for all the mouse events, there seems to be a LOT of info there that is always the same...quite redundant
flackr: we could probably look at removing redundant context stuff, and make sure that everything is captured appropriately in the definition
[we looked specifically at information such as "where do i find out if a pointer event bubbles" ... instead of listing this it specifically for each event like mouse does, it has https://
ACTION: Patrick to merge the event and init definitions for mouse and wheel into a single one, like we do for pointervents, and remove context row from all the mouse/wheel specific event tables (and remove any other redundant info), making sure to hoist any relevant info back to the definitions at the start
<mustaq> FYI: UIEvent.detail is used only in click-like event and mousedown/up:
<mustaq> https://
ACTION: Patrick to consider tweaking introduction/abstract to explain why all of a sudden there are mouse and wheel events in there too
plh to look into talking to editing WG to take over keyboard part of UI events
plh: reached out, timeline around TPAC
plh to move pointerlock-related parts of UI events to pointerlock
plh: not contacted yet, still on my todo list
mustaq: i looked at this, pointerlock spec already includes everything we need, so my suggestion would be to remove the algo in UI events spec, and change references to point directly to pointerlock
plh: will this affect WPTs ? don't think it would... but double-check if any pointerlock tests as part of ui events set of tests
plh: also check MDN/browser data... my guess is you won't need to do that for pointerlock
flackr to look at any duplication we now have about event dispatch/initialisation
Patrick: we've probably covered the initialisation. for dispatch, let's tackle it after that's resolved, as that will be trickier
Any "MouseEvent" issues that need to be prioritised? https://github.com/w3c/pointerevents/issues?q=is%3Aissue%20state%3Aopen%20label%3AMouseEvent
plh: last time we said we want to look at dispatch first, so after we've done the first cleanup of the structure for initialisation first, we should look at the dispatch-specific ones