14:54:46 <RRSAgent> RRSAgent has joined #pointerevents
14:54:46 <RRSAgent> logging to https://www.w3.org/2021/10/13-pointerevents-irc
14:55:01 <Patrick_H_Lauke> Meeting: PEWG
14:55:09 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:56:02 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20211013T110000
14:56:22 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:56:31 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
15:00:44 <flackr> flackr has joined #pointerevents
15:00:51 <Patrick_H_Lauke> present+ smaug
15:00:58 <Patrick_H_Lauke> present+ flackr
15:01:04 <Patrick_H_Lauke> present+ Patrick_H_Lauke
15:02:29 <Patrick_H_Lauke> TOPIC: Move elements of pointerId informative note to normative text https://github.com/w3c/pointerevents/pull/411 (modified after last meeting)
15:04:43 <Patrick_H_Lauke> present+ mustaq
15:05:16 <Patrick_H_Lauke> Patrick: we discussed this already at the last meeting, have modified it since then to hopefully cover the concerns we had.
15:06:46 <Patrick_H_Lauke> 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?
15:11:02 <Patrick_H_Lauke> Flackr: so we're carving out special case for mouse, but otherwise needs to be unique/randomised
15:11:37 <Patrick_H_Lauke> Mustaq: mouse is fine because there's always only one
15:12:00 <Patrick_H_Lauke> Flackr: but same could be said for stylus.... but i think it's ok
15:12:16 <Patrick_H_Lauke> Patrick: i know it's still dense and complex, but i think it's the best we can achieve at this point
15:12:20 <Patrick_H_Lauke> [all agree]
15:12:49 <Patrick_H_Lauke> Flackr: do we need to keep the exception for mouse, allowing it to be a special pointerId
15:20:17 <Patrick_H_Lauke> 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
15:20:40 <Patrick_H_Lauke> [discussion on whether or not "generic" is ... too generic a term]
15:23:34 <mustaq> https://rbyers.github.io/eventTest.html
15:24:08 <mustaq> I used this to check FF and Chrome, they have pointerId 0 and 1 respectively for mouse.
15:25:21 <Patrick_H_Lauke> [checking what WebKit/Safari uses as pointerId for mouse]
15:25:29 <Patrick_H_Lauke> [turns out it's 1]
15:29:48 <Patrick_H_Lauke> Patrick: not hearing any further objections, made the change and now merging.
15:30:09 <Patrick_H_Lauke> TOPIC: 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)
15:30:56 <Patrick_H_Lauke> mustaq: i looked ahead at the second note in https://w3c.github.io/pointerevents/#dfn-active-pointer
15:32:14 <Patrick_H_Lauke> mustaq: i think this can be removed now
15:32:31 <Patrick_H_Lauke> Patrick: yeah that was my feeling as well, i couldn't actually work out anymore what this was *trying* to say
15:32:43 <Patrick_H_Lauke> Flackr: and it's wrong now anyway following the changes we just made
15:33:07 <Patrick_H_Lauke> Patrick: we all happy to remove this note then?
15:33:09 <Patrick_H_Lauke> [all agree]
15:33:26 <Patrick_H_Lauke> ACTION: remove second note from active pointer definition as it's redundant (and wrong) now
15:34:22 <Patrick_H_Lauke> 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?
15:35:35 <Patrick_H_Lauke> Patrick: at a high level...are we "happy" having this vague and non-normative? or should it be normative?
15:35:46 <Patrick_H_Lauke> Smaug: it's ... fine
15:35:55 <Patrick_H_Lauke> mustaq: i think it should be normative
15:39:22 <mustaq> https://www.w3.org/TR/uievents/#events-mouseevent-event-order
15:39:40 <Patrick_H_Lauke> mustaq: UI Events spec handwaves boundary events as well ... spec by example, so we can't overreach by defining things HERE
15:39:43 <mustaq> This "defines" boundary event firing through examples!
15:39:53 <Patrick_H_Lauke> Flackr: agree shouldn't define thing in two places
15:40:09 <Patrick_H_Lauke> mustaq: but maybe we can specify it for target/pointer capture...
15:40:36 <Patrick_H_Lauke> [group agrees that it would end up being complex to define only for capture, and for other events go back to handwaving]
15:40:45 <Patrick_H_Lauke> mustaq: i think one of the problems in this note is the "should"
15:41:10 <Patrick_H_Lauke> Patrick: agree, i was looking at that as well. changing this "should" to "may" would then make everything "may" (lowercase)
15:42:03 <Patrick_H_Lauke> 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
15:42:56 <Patrick_H_Lauke> 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
15:43:06 <Patrick_H_Lauke> Patrick: Rob would you mind taking a stab at this?
15:43:08 <Patrick_H_Lauke> Flackr: sure
15:43:31 <Patrick_H_Lauke> ACTION: Rob to draft a PR for the note regarding pointer capture target override
15:44:03 <Patrick_H_Lauke> 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?
15:54:27 <Patrick_H_Lauke> [discussion on whether the second para about preventDefault is needed? or should be normative]
15:55:39 <Patrick_H_Lauke> 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
15:56:51 <Patrick_H_Lauke> 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
15:57:06 <Patrick_H_Lauke> Patrick: agree, we should just say that canceling prevents compat mouse events, not "some"
15:58:00 <Patrick_H_Lauke> 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
15:58:17 <Patrick_H_Lauke> Patrick: thank you all, catch you again in 2 weeks' time
15:58:46 <Patrick_H_Lauke> actually, tell a lie ... I just realised i'm on vacation then, so 4 weeks' time
16:01:47 <Patrick_H_Lauke> rrsagent, make logs world-visible
16:01:56 <Patrick_H_Lauke> rrsagent, create minutes
16:01:56 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/13-pointerevents-minutes.html Patrick_H_Lauke
16:02:03 <Patrick_H_Lauke> rrsagent, make logs world-visible