- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 11 Sep 2024 17:08:33 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2024/09/11-pointerevents-minutes.html and copied below: PEWG 11 September 2024 Agenda: https://www.w3.org/events/meetings/16b7312b-55ac-4645-8312-0d8103f75519/20240911T110000/ IRC log: https://www.w3.org/2024/09/11-pointerevents-irc Attendees Present flackr, garykac, mustaq, Patrick_H_Lauke Regrets smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Gary Kačmarčík - TPAC plans around algorithmic integration of UI Events and Pointer Events * Limit the precision of floating point event fields w3c/pointerevents#517 * Ensure predicted events only use input from the current partition w3c/pointerevents#518 * W3C Groups Community Survey 2024 https://lists.w3.org/Archives/Public/public-webapps/2024JulSep/0008.html * Triage unlabelled issues https://github.com/w3c/pointerevents/issues * Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 # 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://github.com/w3c/webappswg/wiki/TPAC-2024 <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://github.com/w3c/pointerevents/issues?q=label%3Aneeds-wpt+ 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 -- Patrick H. Lauke * https://www.splintered.co.uk/ * https://github.com/patrickhlauke * https://flickr.com/photos/redux/ * https://mastodon.social/@patrick_h_lauke
Received on Wednesday, 11 September 2024 16:08:42 UTC