Meeting minutes
Gary Kačmarčík - TPAC plans around algorithmic integration of UI Events and Pointer Events
Gary: here to remind you about the joint meeting at TPAC between UI Events and Pointer Events, to discuss how to make PE more algorithmic and to keep PE specific parts clearly in the PE spec, rather than the UI events spec
<mustaq> https://
<mustaq> The discussion will be on Friday Sep 27 9am-10:30am.
Gary: finding the boundaries. so here to ask what do you need out of this. have an initial plan. start thinking about it now before we get to TPAC itself
Rob: mouse events will still be in UI events?
Gary: yes, with a few caveats about new/amended parts
Gary: but yes want to keep core mouse events stuff in UI events
Gary: want to make sure that PE can do everything without having a dependency on UI events
Rob: suspect that targeting of removed nodes for boundary events should probably be a change in UI events, not PE...
Gary: all events have a target, so UI events should define it, yes. i think that's a fairly straightforward change to make, so PE can then point to UI events for THAT aspect
Rob: that part is needed for pointer *capture*, but the node removal part needs to be shared somehow between UI events and PE
Mustaq: i think Gary already has some initial algorithm to cover that. we just need to make it a separate section so we can point to it
Rob: even if you don't do PE, the behavior needs to be defined
Gary: so this was just a heads-up. want to start filing issues, have a broader public discussion, hopefully can come up with some points before TPAC, so then there we can work on the algorithmic side of the spec(s)
Rob: one question for features we were looking at ... we have an issue about default action. we've had the same question about "can we do it for mouse as well" (e.g. defining stylus that does text selection, or mouse doing panning). maybe this CAN be done in PE, but it touches on mouse, so may fall in UI events...
Gary: UI events is broad, and there's no people right now working on that topic. while it sounds like a core thing for UI events, the people discussing it are in PE, so that's where at least the initial discussion/definition can happen. maybe then later push to UI events, tweaks there to support it...
Gary: i.e. start in more specialised group first, then try and see if it can be promoted/pushed to UI events for inclusion
Gary: concern longer term, where you have accessibility - users using one input modality for another (keyboard to move mouse) - it will get more complicated to see where it should live...
Limit the precision of floating point event fields w3c/pointerevents#517
Rob: don't *think* we need to downgrade to float. but wondering WHERE do we currently get this data from. is it not down to physical pixel level? depending on density, you do still want to target physical pixel, so `0.01` won't be precise enough
Rob: don't think we should cap it to a specific number of digits. if UI exposes more than just physical pixel (just talking about coordinates), then that is unnecessary and agree it should be the limit of precision (?)
[group looking at other values that use float]
Rob: for anything on screen, physical pixel should be the minimum. what's the minimum for others - tilt ... 0.1 degress probably enough, in radians need it more precise ...
Patrick: pressure.... 0.1 possibly enough? not sure how good the sensors even are
Rob: you also don't want to introduce steps ... if it's going for pressure from 0 to 1, you don't want to artifically create steps when the device would be capable of passing on smoother change from 0 to 1
Rob: we should err on the side of being more precise rather than less precise...
Mustaq: one fingerprinting problem i can imagine ... my hand is shaky, but the shake would be at physical pixel level. so won't be able to completely prevent fingerprinting
Patrick: for shaky hands etc it's likely the user would want to set something at OS level like smooth mouse. beyond that, the concern of "this device is known to have a sensor that fluctuates in a known frequency, so i can detect that". it's an info science problem ... what's noise, what's information
ACTION: iterate over this in the issue, see if we can establish some baseline numbers and wording
Ensure predicted events only use input from the current partition w3c/pointerevents#518
Patrick: i could try wordsmithing to clarify that "past points" means literally the preceding few points
Rob: I think it will be trickier though, because the OS/UA may have *learnt* how your movement works, to make its own guesses (even just based on the preceding points) better
Patrick: isn't that what Apple have introduced recently? that it makes your handwriting/notetaking "better"
Rob: do we limit how far into the future it predicts? don't want to start a stroke, and it can predict that you're wanting to do your signature, and completes it
ACTION: iterate over this in the issue - patrick to start with the first monkeypatch to clarify "past points", then we can work on extra additional info about limiting future
<mustaq> Limiting by time is tricky: what if a user completes their signature in half a second?
W3C Groups Community Survey 2024 https://lists.w3.org/Archives/Public/public-webapps/2024JulSep/0008.html
Patrick: this is at member level, not group level. so please make sure to fill in the survey. deadline Friday 13th (2 days from now)
Triage unlabelled issues https://github.com/w3c/pointerevents/issues
Patrick: please take time to label any unlabelled issues, check what could still be considered v3-blocking (as we're still waiting for privacy wide review and can't move to REC track before that anyway), or "future"
ACTION: group to triage remaining issues
Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445
Mustaq: only one left, but think Rob fixed it https://
Rob: maybe not fully fixed, have to double-check
Rob: i also identified that there's a change we should make. when we fail capture because it's a different frame, we should throw an error, similar to other cases where capture fails
Mustaq: currently fails silently?
Rob: yes. if you look at spec, the algorithm says throw error, but if it's a different context/frame, just stop. should change spec there to make it consistent. then update the test
Rob: also, when i wrote test, it seemed to allow capture to a subframe, but per spec it shouldn't happen. but in real browsers, i couldn't replicate that, so maybe something changed in the test
Mustaq: i think i remember this (that at some point it allowed it in chrome)
Rob: if you're allowed to capture to a subframe, why can't you capture to a parent frame?
Mustaq: we had some use case...can't remember
Rob: in all cases requires same origin. can't call setPointerCapture if different origin
Rob: so not sure why we even have this restriction
<flackr> The added test is /pointerevents/pointerevent_pointercapture_in_frame.html
Mustaq: ... maybe we got this from the old microsoft spec...
Rob: maybe worth digging into original reason, if argument still applies, then revisit
Patrick: i want to say the original case was about things like adverts inside frames, and that was in the very early spec BEFORE we had the same origin requirement
Mustaq: also, back in the early days, the pointerId was global, not specifically different per context
Rob: and we constrained WHEN capturing can happen, event-wise
Rob: think you should allow setPointerCapture up and down the frame if they're in same origin, and silently failing if cross-origin is fine
Rob: should be consistent with setPointerCapture on a non-existent/inactive pointer, because from the perspective of the (cross-origin) subframe that pointer doesn't exist
Rob: i'll open an issue
ACTION: Rob to open issue about changes to algorithm to allow subframe to parent capture on same origin, silently fail if cross-origin
Patrick: thank you all. next time we see each other will be at TPAC