– DRAFT –
PEWG

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