Meeting minutes
<flackr> w3c/
Rob: this is a feature that MS has been incubating for a while, now is the time for us to decide if we want to go for it
Clarify mousedown event target if the preceding pointerdown event listener removes the target #492 w3c/pointerevents#492
associated PR w3c/
Patrick: I believe Olli you thumbsed up the PR
Mustaq: as Olli mentions, there are handwavy aspects, but it may be ok to merge at this stage
Mustaq: i've used the underscore for `user_event`, because as programmer i didn't feel good about using a space
Patrick: are we using underscore or space then?
Flackr: i think i prefer space
Olli: DOM spec uses camelCase
<smaug> https://
Mustaq: I can switch to camelCase, then we can merge
ACTION: Mustaq to change user_event to camelCase, then we merge
Patrick: so will this close the issue #492 for sure?
<mustaq> w3c/
Mustaq: while there are other related aspects like the above, I think this will let us close #492
<mustaq> So I think my PR can close the PE issue
Note/discussion: Consider splitting [UI Events] spec into smaller specifications
#369 https: //github.com/w3c/uievents/issues/369
Patrick: this is more a "be aware of this" and comment on it if you have strong feelings about it
<mustaq> Gary's proposal for 5.3 and 5.4: wheel events should also be part of pointer events spec?
[discussion on should mouse and pointer events merge somehow to avoid the whole PE extends mouse events]
Make pointerenter definition similar to pointerover w.r.t. pointerdown from a touch pointer #497 w3c/pointerevents#497
Mustaq: pointerdown definition looks correct, but pointerover event doesn't
<mustaq> Look at the diffs in 4.2.1 and 4.2.2
Mustaq: pointerdown special case is missing
<mustaq> in the first sentences.
Mustaq: ah, it's just different order. I'll close the issue
ACTION: Mustaq to close issue
Update https://github.com/web-platform-tests/wpt/blob/master/pointerevents/META.yml #498 w3c/pointerevents#498
Olli: a tool was using this to assign things to Rick/Navid, should we update this
<mustaq> Looks like the file is manually updated: https://
ACTION: Olli to update the file in WPT repo
Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445
Olli: didn't get chance for new issues. worked on issues for interop 2023
Mustaq: no progress from my side either. hoping to land the PR discussed earlier
Olli: i think some WPTs had to be backed out recently because they broke interop2023 scoring
<smaug> web-platform-tests/
Patrick: i think unless i'm looking at wrong link, doesn't look bad where we are https://
<smaug> https://
Add logical/abstract values for touch-action #496 w3c/pointerevents#496
Patrick: we had an issue opened ages ago about this, and as I was pondering this recently, wanted to make a PR just to get a sense
Rob: just to check that the writing mode etc that matters is the one defined on the element that has the touch-action, and NOT the writing mode specifically inside the container that is being interacted with
Patrick: that's what i would imagine ... what counts is the writing mode on the element that has the touch-action, regardless of writing modes of child elements
Patrick: similarly, we probably want to explicitly mention that if writing mode changes while a gesture/action is already in progress, then that's ignored - same as how touch-action changing in the course of a gesture/action is ignored
Multi-pen support and persistent pointerId #353
Olli: do you know if MS has been implementing that, or is it windows only
<mustaq> w3c/
Rob: i reviewed many of the patches of the implementation, we landed on approach that does take the underlying device id from other platforms (linux, chromeOS, not confident on mac)
Olli: proposal that intel brought was chromeOS only, IIRC
Rob: supports identifying device on linux and chromeOS in a slightly different way than windows - but the concept of the device producing the event giving you a consistent ID is something that can be implemented on different platforms
Rob: they've been trying to come resolution to this in a couple of years. so far i can tell the device id ... there's two reasonable answers: making something LIKE pointerId but not available at the start of the detection; or adding some additional event when the deviceId becomes known for a given pointer. don't like the latter, have preference towards the approach they landed on. extension of pointerId. strictly speaking[CUT]
y do is supported by PE...
Mustaq: the concept of info only known on down is not unique though, right?
Rob: similar to intel's proposal about "this stylus wants to draw in a particular colour"
Rob: maybe way to merge this idea with the intel one is to define some sort of structure that can be expanded beyond just deviceId, to also include info like preferred colour etc
Rob: if we can come up with something now, MS would likely be happy to change this in their implementation without us ending up locked in with a deviceId on the top-level events properties
Rob: Intel had "penCustomisationDetails" (sp?) which is too specific. but maybe deviceInfo or something like that
PAtrick: flashback to the device capabilities https://
Rob: let's give them a prop that they can hang their deviceId from
<mustaq> WICG/
Olli: i'd love THEM to come up with something
Rob: I can take it to them - this is our concern, we'd like to put this behind a more flexible structure, that could then also accommodate other properties like Intel's proposed one
ACTION: Rob to speak to Microsoft about using a more generalised structure for the deviceId info
Patrick: once Mustaq's PR is ready, I'll merge it, then proceed with finally sending this out for wide review (after refreshing my memory on which groups I need to contact etc). Thank you all, catch you in 2 weeks' time