- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 13 Oct 2021 17:10:01 +0100
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2021/10/13-pointerevents-minutes.html and copied below: PEWG 13 October 2021 Agenda: https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20211013T110000 Attendees Present flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Move elements of pointerId informative note to normative text https://github.com/w3c/pointerevents/pull/411 (modified after last meeting) * Notes with normative (SHOULD/MUST) statements https://github.com/w3c/pointerevents/issues/405 (6 instances addressed, 1 awaiting PR review above, 3 more that need discussion) # Move elements of pointerId informative note to normative text https://github.com/w3c/pointerevents/pull/411 (modified after last meeting) Patrick: we discussed this already at the last meeting, have modified it since then to hopefully cover the concerns we had. Patrick: do we think this now still addresses ... what it originally tried to address? privacy concerns/fingerprinting, while also allowing reuse of pointerId numbers and "fixing" pointerId for specific devices? Flackr: so we're carving out special case for mouse, but otherwise needs to be unique/randomised Mustaq: mouse is fine because there's always only one Flackr: but same could be said for stylus.... but i think it's ok Patrick: i know it's still dense and complex, but i think it's the best we can achieve at this point [all agree] Flackr: do we need to keep the exception for mouse, allowing it to be a special pointerId Patrick: looking at the second sentence, maybe we should add another word "*generic* pointerId" there to avoid scenarios where a UA decides to fingerprint a user by assigning them a specific unique pointerId for their mouse and then letting sites track that user [discussion on whether or not "generic" is ... too generic a term] <mustaq> https://rbyers.github.io/eventTest.html <mustaq> I used this to check FF and Chrome, they have pointerId 0 and 1 respectively for mouse. [checking what WebKit/Safari uses as pointerId for mouse] [turns out it's 1] Patrick: not hearing any further objections, made the change and now merging. # Notes with normative (SHOULD/MUST) statements https://github.com/w3c/pointerevents/issues/405 (6 instances addressed, 1 awaiting PR review above, 3 more that need discussion) mustaq: i looked ahead at the second note in https://w3c.github.io/pointerevents/#dfn-active-pointer mustaq: i think this can be removed now Patrick: yeah that was my feeling as well, i couldn't actually work out anymore what this was *trying* to say Flackr: and it's wrong now anyway following the changes we just made Patrick: we all happy to remove this note then? [all agree] ACTION: remove second note from active pointer definition as it's redundant (and wrong) now Patrick: next up > note in https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface ... contains "may" and "should", but not sure how strongly this is intended. they're not capitalised, but may give impression of being MAY and SHOULD in normative sense? more fundamentally, are we ok with not normatively defining if boundary events are fired or not? Patrick: at a high level...are we "happy" having this vague and non-normative? or should it be normative? Smaug: it's ... fine mustaq: i think it should be normative <mustaq> https://www.w3.org/TR/uievents/#events-mouseevent-event-order mustaq: UI Events spec handwaves boundary events as well ... spec by example, so we can't overreach by defining things HERE <mustaq> This "defines" boundary event firing through examples! Flackr: agree shouldn't define thing in two places mustaq: but maybe we can specify it for target/pointer capture... [group agrees that it would end up being complex to define only for capture, and for other events go back to handwaving] mustaq: i think one of the problems in this note is the "should" Patrick: agree, i was looking at that as well. changing this "should" to "may" would then make everything "may" (lowercase) mustaq: difference is that UI Events is talking about mouse events, but here we do it for pointer, and specifically about capture, so maybe we should be more specific Flackr: don't want to talk about boundary events specifically, but maybe we need to say that using target capture should be treated as if the pointer moved to the element Patrick: Rob would you mind taking a stab at this? Flackr: sure ACTION: Rob to draft a PR for the note regarding pointer capture target override Patrick: last one from this batch: > first note in https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events is full of "may" and "should" - is it clear enough these are not used in the MAY and SHOULD sense? [discussion on whether the second para about preventDefault is needed? or should be normative] Patrick: I think what we do want to make normative is the first sentence, saying that click/contextmenu are NOT considered compat mouse events. then leave the "In user agents that support..." as part of the note Flackr: agree. also, the fact that in the default actions listed for pointerdown etc it's very vaguely talking about canceling "some" mouse compat events is a bit too vague Patrick: agree, we should just say that canceling prevents compat mouse events, not "some" ACTION: Patrick to draft a PR that makes sentence about click/contextmenu NOT being compat events normative, make the default action explanations about canceling and how that affects compat mouse events MORE specific by remove the vagueness on which ones are prevented Patrick: thank you all, catch you again in 2 weeks' time actually, tell a lie ... I just realised i'm on vacation then, so 4 weeks' time -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 13 October 2021 16:10:19 UTC