- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 9 Oct 2024 17:09:13 +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/10/09-pointerevents-minutes.html and copied below: PEWG 09 October 2024 Agenda: https://www.w3.org/events/meetings/66591f6b-6694-4f90-b23d-bf8f1b9dda8a/20241009T110000/ IRC log: https://www.w3.org/2024/10/09-pointerevents-irc Attendees Present: adettenb, flackr, mustaq, Olga, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick_H_Lauke * Limit the precision of floating point event fields w3c/pointerevents#517 * Ensure predicted events only use input from the current partition w3c/pointerevents#518 * [PointerEvent algorithms] Order of boundary events w3c/pointerevents#519 * [touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516 * Coalesced and predicted event attributes within an untrusted event w3c/pointerevents#514 * Ambiguity of the value of the button property for the click event w3c/pointerevents#513 * Triage unlabelled issues https://github.com/w3c/pointerevents/issues * Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 [quick round of introductions for the benefit of Olga and Adam, new WG members joining us from Microsoft] # Limit the precision of floating point event fields w3c/pointerevents#517 Rob: meant to write something up, but as mentioned in previous meeting: location should be at least pixel level; and we need to be careful about potential banding if we artificially limited precision that would then lead to jumps (e.g. pressure) ACTION: continue iterating, Rob to write up a few thoughts on the issue # Ensure predicted events only use input from the current partition w3c/pointerevents#518 Patrick: i promised that i'd monkey-patch this to at least make it clear what we mean by "past" (i.e. the preceding points of the current gesture/interaction, not "when the user last visited this a few days ago"). suggest i'll do this for next meeting, then we have something to expand further Rob: also limit it specifically to "current webpage" or similar, be very specific, to make it clear devs won't have more access to things than they should ACTION: Patrick to make first pass PR to clarify # [PointerEvent algorithms] Order of boundary events w3c/pointerevents#519 mustaq: UI events spec wants to become more algorithmic, and that showed up a few discrepancies with our own handling. this was before TPAC. but at TPAC it was decided that UI events will handle mouse events (?) <mustaq> https://www.irccloud.com/pastebin/wmpUV7lT/ https://www.w3.org/2024/09/WebAppsWG-TPAC2024-Meetings-Minutes.pdf mustaq: there are four of these algorithm issues altogether. they're more longer-term. not for Level 3 Olli: agree this is more for Level 4, Next ... post Level 3 Rob: we have clear direction, we just need to make sure it's all handled consistently Adam: is it that mouse events currently are getting turned into pointer events, for enter/leave... mustaq: not a problem of event per se, but which spec specifies the behavior Rob: developers won't see any difference. it's just which order, which timing, events are being fired # [touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516 Adam: in short, we need a way to separate handwriting from scrolling behavior Adam: e.g. an app adds a toggle to explicitly switch between handwriting and regular pointing device for their stylus Adam: one proposal was to do this as an attribute in HTML. another idea was to piggy-back on touch-action as a new value to differentiate between handwriting and panning Adam: no way currently to allow granular control <mustaq> w3c/pointerevents#203 Rob: the way we built stylus on android is that handwriting is equivalent to scrolling (?) Rob: not sure if 203 is same issue. when you put stylus down, you CAN pan, you CAN write, nothing for author to stop one or the other Adam: you can only limit pan to one direction, but not completely suppress pan AND allow handwriting Rob: pan and manipulation might disable handwriting Rob: problem is that touch action is applied as a bitmask down the tree ... if the parent limits to just panning, for instance, it would then disable handwriting further down Olga: so we won't be able to enable handwriting on a child if parent has limited to just pan Rob: if we don't include handwriting as a concept as part of pan Olga: as Adam pointed out, this might be more a problem for older pages, but not for new ones Adam: yes, new ones may already take that into account. so adding a new value for handwriting to touch-action sounds like the way to go Rob: might be worth also thinking about other actions like text selection Adam: should it be included in the manipulation set? mustaq: in Chrome manipulation is pan and zoom Rob: i think it should probably be in manipulation Rob: we should have some other property to determine whether you want ... how you want to treat these devices, but maybe touch-action is sufficient. in other issue (512) i talk about how we might want to allow mice to pan. that's more a "how to treat this device" Olga: in future it could allow handwriting with mouse (in ref to 512) mustaq: in reference to 203, that was a wider idea of moving away from touch-action to a few more specific properties Olli: is there a situation where you'd also want different pointers/styli to behave differently? Adam: some styluses support things like a toggle/switch to trigger different behaviors, stylus with eraser. not sure what that would look like Olga: to be clear, we just want to allow author to specify that they want to allow handwriting with a pointer (stylus, finger) rather than interpreting it as a pan (?) mustaq: what to do when a device doesn't support handwriting? should it fall back to then allowing pan? mustaq: what i imagine is a page with lots of inputs, and you want to allow an author to say "for touch, just pan; for pen, make it do handwriting" Adam: would be good to allow both, but have handwriting take precedence. Would be useful to allow defining different behaviors for different pointer types too <mustaq> w3c/pointerevents#203 (comment) mustaq: there's no consensus there, but the issue there mentions this idea of making it more granular / per pointer type <mustaq> pointer-action: touch(pan-y), pen(none); ACTION: iterate further on the issue w3c/pointerevents#516 - Adam to flesh out further thoughts/ideas (also in light of 203) # Coalesced and predicted event attributes within an untrusted event w3c/pointerevents#514 mustaq: my concern was that authors may trust the trusted bit too much, even though the list comes from an untrusted event... ACTION: mustaq to propose a PR with clarification, Olli to review # Ambiguity of the value of the button property for the click event w3c/pointerevents#513 Olli: ...in this case click needs to follow UI events mustaq: the special case i proposed will be breaking... Olli: we can't change behaviour, just need to clarify it ACTION: Patrick to attempt first PR to clarify/document this # Triage unlabelled issues https://github.com/w3c/pointerevents/issues # Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 mustaq: think we only have one left at this point. Rob landed it, but it was reverted. w3c/pointerevents#300 ACTION: Rob to review his WPT (and why it might have been reverted) -- 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, 9 October 2024 16:09:19 UTC