14:47:33 <RRSAgent> RRSAgent has joined #pointerevents
14:47:37 <RRSAgent> logging to https://www.w3.org/2024/09/11-pointerevents-irc
14:47:37 <Patrick_H_Lauke> present+
14:48:01 <Patrick_H_Lauke> regrets+ smaug
14:48:15 <Patrick_H_Lauke> Meeting: PEWG
14:48:42 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:48:54 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/16b7312b-55ac-4645-8312-0d8103f75519/20240911T110000/
14:49:04 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:49:08 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
15:01:04 <flackr> flackr has joined #pointerevents
15:03:13 <Patrick_H_Lauke> present+ flackr
15:03:22 <Patrick_H_Lauke> present+ mustaq
15:04:20 <garykac> garykac has joined #pointerevents
15:04:29 <Patrick_H_Lauke> present+ garykac
15:04:51 <Patrick_H_Lauke> TOPIC: Gary Kačmarčík - TPAC plans around algorithmic integration of UI Events and Pointer Events
15:06:07 <Patrick_H_Lauke> 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
15:06:37 <mustaq> https://github.com/w3c/webappswg/wiki/TPAC-2024
15:07:08 <mustaq> The discussion will be on Friday Sep 27 9am-10:30am.
15:07:10 <Patrick_H_Lauke> 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
15:07:33 <Patrick_H_Lauke> Rob: mouse events will still be in UI events?
15:08:03 <Patrick_H_Lauke> Gary: yes, with a few caveats about new/amended parts
15:08:15 <Patrick_H_Lauke> Gary: but yes want to keep core mouse events stuff in UI events
15:08:33 <Patrick_H_Lauke> Gary: want to make sure that PE can do everything without having a dependency on UI events
15:08:58 <Patrick_H_Lauke> Rob: suspect that targeting of removed nodes for boundary events should probably be a change in UI events, not PE...
15:09:32 <Patrick_H_Lauke> 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
15:10:07 <Patrick_H_Lauke> Rob: that part is needed for pointer *capture*, but the node removal part needs to be shared somehow between UI events and PE
15:10:40 <Patrick_H_Lauke> 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
15:10:58 <Patrick_H_Lauke> Rob: even if you don't do PE, the behavior needs to be defined
15:11:47 <Patrick_H_Lauke> 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)
15:14:35 <Patrick_H_Lauke> 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...
15:15:24 <Patrick_H_Lauke> 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...
15:15:55 <Patrick_H_Lauke> Gary: i.e. start in more specialised group first, then try and see if it can be promoted/pushed to UI events for inclusion
15:17:07 <Patrick_H_Lauke> 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...
15:17:59 <Patrick_H_Lauke> TOPIC: Limit the precision of floating point event fields https://github.com/w3c/pointerevents/issues/517
15:20:44 <Patrick_H_Lauke> 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
15:23:04 <Patrick_H_Lauke> 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 (?)
15:23:39 <Patrick_H_Lauke> [group looking at other values that use float]
15:24:50 <Patrick_H_Lauke> 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 ...
15:25:34 <Patrick_H_Lauke> Patrick: pressure.... 0.1 possibly enough? not sure how good the sensors even are
15:26:19 <Patrick_H_Lauke> 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
15:28:26 <Patrick_H_Lauke> Rob: we should err on the side of being more precise rather than less precise...
15:34:09 <Patrick_H_Lauke> 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
15:35:06 <Patrick_H_Lauke> 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
15:35:41 <Patrick_H_Lauke> ACTION: iterate over this in the issue, see if we can establish some baseline numbers and wording
15:35:56 <Patrick_H_Lauke> TOPIC: Ensure predicted events only use input from the current partition https://github.com/w3c/pointerevents/issues/518
15:40:11 <Patrick_H_Lauke> Patrick: i could try wordsmithing to clarify that "past points" means literally the preceding few points
15:40:55 <Patrick_H_Lauke> 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
15:41:29 <Patrick_H_Lauke> Patrick: isn't that what Apple have introduced recently? that it makes your handwriting/notetaking "better"
15:42:02 <Patrick_H_Lauke> 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
15:44:22 <Patrick_H_Lauke> 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
15:44:35 <mustaq> Limiting by time is tricky: what if a user completes their signature in half a second?
15:45:59 <Patrick_H_Lauke> TOPIC: W3C Groups Community Survey 2024 https://lists.w3.org/Archives/Public/public-webapps/2024JulSep/0008.html
15:47:30 <Patrick_H_Lauke> 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)
15:48:03 <Patrick_H_Lauke> TOPIC: Triage unlabelled issues https://github.com/w3c/pointerevents/issues
15:50:10 <Patrick_H_Lauke> 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"
15:50:20 <Patrick_H_Lauke> ACTION: group to triage remaining issues
15:50:34 <Patrick_H_Lauke> TOPIC: Meta-issue: update WPT to cover Pointer Events Level 3 #445 https://github.com/w3c/pointerevents/issues/445
15:51:01 <Patrick_H_Lauke> Mustaq: only one left, but think Rob fixed it https://github.com/w3c/pointerevents/issues?q=label%3Aneeds-wpt+
15:51:12 <Patrick_H_Lauke> Rob: maybe not fully fixed, have to double-check
15:51:52 <Patrick_H_Lauke> 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
15:51:59 <Patrick_H_Lauke> Mustaq: currently fails silently?
15:52:37 <Patrick_H_Lauke> 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
15:53:20 <Patrick_H_Lauke> 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
15:53:52 <Patrick_H_Lauke> Mustaq: i think i remember this (that at some point it allowed it in chrome)
15:54:13 <Patrick_H_Lauke> Rob: if you're allowed to capture to a subframe, why can't you capture to a parent frame?
15:54:29 <Patrick_H_Lauke> Mustaq: we had some use case...can't remember
15:54:46 <Patrick_H_Lauke> Rob: in all cases requires same origin. can't call setPointerCapture if different origin
15:54:55 <Patrick_H_Lauke> Rob: so not sure why we even have this restriction
15:56:09 <flackr> The added test is /pointerevents/pointerevent_pointercapture_in_frame.html
15:57:58 <Patrick_H_Lauke> Mustaq: ... maybe we got this from the old microsoft spec...
15:58:14 <Patrick_H_Lauke> Rob: maybe worth digging into original reason, if argument still applies, then revisit
15:59:57 <Patrick_H_Lauke> 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
16:00:29 <Patrick_H_Lauke> Mustaq: also, back in the early days, the pointerId was global, not specifically different per context
16:00:47 <Patrick_H_Lauke> Rob: and we constrained WHEN capturing can happen, event-wise
16:01:15 <Patrick_H_Lauke> 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
16:02:01 <Patrick_H_Lauke> 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
16:02:47 <Patrick_H_Lauke> Rob: i'll open an issue
16:03:17 <Patrick_H_Lauke> ACTION: Rob to open issue about changes to algorithm to allow subframe to parent capture on same origin, silently fail if cross-origin
16:03:36 <Patrick_H_Lauke> Patrick: thank you all. next time we see each other will be at TPAC
16:03:41 <Patrick_H_Lauke> rrsagent, set logs world-visible
16:03:46 <Patrick_H_Lauke> rrsagent, generate minutes
16:03:47 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/11-pointerevents-minutes.html Patrick_H_Lauke
16:04:00 <Patrick_H_Lauke> rrsagent, set logs world-visible
16:09:05 <Patrick_H_Lauke> rrsagent, bye
16:09:05 <RRSAgent> I see 4 open action items saved in https://www.w3.org/2024/09/11-pointerevents-actions.rdf :
16:09:05 <RRSAgent> ACTION: iterate over this in the issue, see if we can establish some baseline numbers and wording [1]
16:09:05 <RRSAgent>   recorded in https://www.w3.org/2024/09/11-pointerevents-irc#T15-35-41
16:09:05 <RRSAgent> 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 [2]
16:09:05 <RRSAgent>   recorded in https://www.w3.org/2024/09/11-pointerevents-irc#T15-44-22
16:09:05 <RRSAgent> ACTION: group to triage remaining issues [3]
16:09:05 <RRSAgent>   recorded in https://www.w3.org/2024/09/11-pointerevents-irc#T15-50-20
16:09:05 <RRSAgent> ACTION: Rob to open issue about changes to algorithm to allow subframe to parent capture on same origin, silently fail if cross-origin [4]
16:09:05 <RRSAgent>   recorded in https://www.w3.org/2024/09/11-pointerevents-irc#T16-03-17