- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 29 Jan 2025 18:18:42 +0000
- To: public-pointer-events@w3.org
Dear all, the minutes from today's meeting are at https://www.w3.org/2025/01/29-pointerevents-minutes.html and copied below: PEWG 29 January 2025 Agenda: https://www.w3.org/events/meetings/66591f6b-6694-4f90-b23d-bf8f1b9dda8a/20250129T110000/ IRC log: https://www.w3.org/2025/01/29-pointerevents-irc Attendees Present flackr, mustaq, Patrick_H_Lauke Regrets smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Action items from previous meeting * Clarify that click, auxclick and contextmenu get their .button and .buttons behavior from UIEvents w3c/pointerevents#531 * Implicit pointer capture state after a failed explicit capture call at pointerdown w3c/pointerevents#534 * Define pointermove and pointerrawupdate may have delta from previous corresponding pointer event as movementX and movementY w3c/pointerevents#535 * Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 * Olli's webcompat issue https://bugzilla.mozilla.org/show_bug.cgi?id=1943411 # Action items from previous meeting Rob to follow up on w3c/pointerevents#516 Rob: CSS WG has a bot that files minutes to issues, can we have that? Patrick: I'll ask PLH context of the action was https://www.w3.org/2024/12/18-pointerevents-minutes.html#ee66 mustaq: didn't we say we'd explore other avenues other than PE? i might be misremembering Patrick: we already decided that we'd defer this to future, not cramming into v3, so no major rush https://www.w3.org/2024/12/04-pointerevents-minutes.html#d477 [Group discusses again the intricacies of new handwriting touch-action, and where this new value would need to be assumed to be included, and other cases where authors will have to explicitly add it, e.g. when they explicitly defined a touch-action for pan-x but they now ALSO want handwriting, but in other cases it has to be assumed like for touch-action: none] Patrick: can we add something to w3c/pointerevents#516 ACTION: Rob to add a small reminder (to ourselves, mainly) what our current thinking/challenges are for w3c/pointerevents#516 Patrick: other action we had was - Group to review w3c/pointerevents#532 for this meeting mustaq: on the outstanding comment from Rob - think we want to call out primary pointer mainly because no implementation does hover for anything other than primary Rob: seems strange that you get boundary updates for one finger rather than ohters mustaq: wanted to maintain what UI Events spec does ... at least my interpretation. this calculation is expensive, so i think that's the rationale for calling out primary, since that's also only one that hovers. i can open a new issue separately, or we can work still on this PR Rob: with this PR we match mouseover/mouseout behaviour for the primary pointer event Rob: UI Events talks about mouse, and then introduces primary pointer...which is confusing Rob: maybe we limit this to cases where you only have one active pointer, which is the primary pointer of the current type Rob: primary touch is only primary while there's only one touch? mustaq: you mouse hovering element A, you tap element B. does the mouse jump? on some implementations it does, on others the mouse pointer disappears Rob: i think the visible movement of mouse is a legacy from older touch devices... Patrick: that's more a visual UI thing left up to UAs, not something that concerns us anyway. the "disappeared" mouse pointer moves to where your touch was, and when you wiggle the mouse again the UA decides to either start from that touch position, or from the previously known mouse position (?) Rob: we might only be able to do this for devices that DON'T have implicit capture Rob: hover effect is only caused by the legacy mouse pointer. because touch has implicit capture, maybe we don't need to worry as you can't change the target underneath it... (?) Rob: ... unless you removed capture, which I think you can do / release Rob: which is going to be an edge case mustaq: i think implicit capture is the only one that makes the distinction.... <flackr> https://w3c.github.io/pointerevents/#implicit-pointer-capture Rob: you raised performance, but if we assume that a captured pointer doesn't change its target, we don't need to worry about it...so performance hit only for edge case? Rob: we can remove that whole active pointer requirement, and have no perf hit, because most times pointers will be captured mustaq: so I should remove the primary condition bit mustaq: do we need to discuss further, or we settled Rob: to make everything nice and consistent, this seems to make sense mustaq: there was also a comment from masayuki, but that's a separate issue. he approved the PR, so we can leave that for another issue ACTION: mustaq to remove "primary" from w3c/pointerevents#532 and we then merge # Clarify that click, auxclick and contextmenu get their .button and .buttons behavior from UIEvents w3c/pointerevents#531 mustaq: approve that an hour ago, looks good to me Patrick: I'll massage the wording slightly and then merge ACTION: Patrick to tweak and merge w3c/pointerevents#531 # Implicit pointer capture state after a failed explicit capture call at pointerdown w3c/pointerevents#534 mustaq: implict pointer capture is set by browser, and author can then release or set different capture. what happens if this JS by the author fails? Rob: what happens now in general when second capture doesn't work/calls it twice? mustaq: then only the first one "takes" Rob: so seems consistent mustaq: will check if WPT covers this already, if it does i'll close issue, otherwise will comment there and keep open ACTION: mustaq to review w3c/pointerevents#534 if it's already covered by WPT Define pointermove and pointerrawupdate may have delta from previous corresponding pointer event as movementX and movementY w3c/pointerevents#535 mustaq: looks reasonable Rob: yes Patrick: so question - do we want this in v3 or defer. how easy/hard is it to add to our spec? looks like it might involve a lot of extra writing and defining new things mustaq: think we don't even mention movementX/movementY in PE spec. so this looks like it'd need a lot of work - ripping it out of mouse event spec Rob: not even in mouse event spec, it's an extension to pointer lock spec Rob: seems like pointer lock could/should extend pointer event, rather than other way around Rob: in the linked section https://w3c.github.io/pointerlock/#extensions-to-the-mouseevent-interface Rob: so if pointerlock extended PointerEvent rather than MouseEvent, this would be handled for free Rob: pointerevents extend mousevents, but yes it should be defined/mentioned in pointerlock, not in pointervents spec mustaq: so we should open an issue against pointerlock, and close the issue at our end? Rob: sounds reasonable ACTION: mustaq to close/move w3c/pointerevents#535 to pointerlock spec # Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 Patrick: I think nominally we only have one that needs WPT https://github.com/w3c/pointerevents/issues?q=label%3Aneeds-wpt+ mustaq: this sounds tricky ... related to what we just discussed with pointerlock... [discussion on what happens in chrome with dom event change signalling that target needs to be recalculated. might not happen for the events dispatched already in the current tick] Rob: want to avoid needing to continuously do hit tests mustaq: the ancestor checking couldn't be shipped in chrome due to interop... Rob: interop issue not in Firefox though, so it's something in Chrome's implementation mustaq: it was some shadow DOM behaviour Patrick: so is this realistically something we can look at for v3? Rob: we could test state we're currently in - does target change for the move for pointerevents, mousevents, ... if you modify the DOM in events that are synchronously part of the same event stream Rob: might be a similar question ... maybe with focus, or similar UI events, that have a similar problem Patrick: so something that can be explored for next time? Rob: pointerrawupdate i thought the point was that we determine the target from the last non-raw update mustaq: because the last raw event may NOT be coalesced Rob: does it do a hit test, or take target from the last move? mustaq: so it "seems" to be v3 blocking Rob: doesn't introduce a new feature, relates to accurately describing current spec behaviour ACTION: for next meeting, review w3c/pointerevents#509 # Olli's webcompat issue https://bugzilla.mozilla.org/show_bug.cgi?id=1943411 Rob: this is the thing we just discussed "Masayuki and others analyzed that and he then wrote a patch which mimics Chrome Canary's behavior. Release Chrome does something a tiny bit different, I think either the test for mousemove or for the pointer events fail there. Tests are in https://phabricator.services.mozilla.com/D235807 I don't think the specs define too accurately what the behavior should be." <mustaq> Mozilla change: https://phabricator.services.mozilla.com/D235807 Rob: my intuition is that at the point we generate enter event, we already determined the target of the move Rob: pretty sure for enter event we dispatch it to the removed node Rob: we could dispatch to the removed node even though you're not supposed to do that (?) Rob: ... this is all part of the same problem - we assume that the DOM doesn't change in between these events Rob: not a terrible assumption.. Patrick: apologies, we're over time and i hadn't realised. thank you as ever, catch you in two weeks' time # Summary of action items * Rob to add a small reminder (to ourselves, mainly) what our current thinking/challenges are for w3c/pointerevents#516 * mustaq to remove "primary" from w3c/pointerevents#532 and we then merge * Patrick to tweak and merge w3c/pointerevents#531 * mustaq to review w3c/pointerevents#534 if it's already covered by WPT * mustaq to close/move w3c/pointerevents#535 to pointerlock spec for next meeting, review w3c/pointerevents#509 -- 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, 29 January 2025 18:18:50 UTC