Alice: I had a read through it. I read through the issue thread as well. Anne had some questions about interaction with shadow dom, and some questions about the implementability of the spec. Does anyone else have context on pointer events?

David: IIRC, multitouch was original motivation. Redesign mouse events with knowledge that multitouch exists.

Sangwhan: competing with touch events, but it has issues. So we have 3 different things to capture pointer input.

Dan: Many loud advocates for pointer events approach that want it implemented more widely.

Alice: So, this didn't have an explainer. Looked at the demo, didn't have explanation. Was a bit frustrating. It adds some APIs into the PointerEvent interface: getCoalescedEvents and getPredictedEvents. I don't know what predicted events are...

Dan: Maybe we should just push back that there's no explainer; we should ask for that before we do a review.

Alice: Open questions: what are predicted events for? (second question missed) Plus Anne's comments about implementability of the spec.

Alice: OK, I can comment with that.

(digression about knowing who's commenting on the issues)

(Lukasz leaves)

Sangwhan: I can see if I can disambiguate this -- been a long time since I touched pointer events in Presto.

Dan: Co-owner of issue with Alice?

Sangwhan: I can.

Dan: Postpone to when?

Sangwhan: This was expedited... so next week if possible? If Alice has time I could set up a separate call this week or next to discuss this.

Alice: next would be good

Dan: So next week, but bump to later if you want to

Alice: my feedback was asking for an explainer. My opnion is that the API looks fine - it's adding this pointerrawupdate event which is a spammy event - finegrained events on that. spec has comments like "don't handle this unless you have fast code handling it" - the getpredictedevents API is copying some platform ... I asked a question about why the browser needs to do this. Sangwhan pointed out that if the browser is doing it it happens off the main thread... Anne also had points about shadow dom.

David: Anne was considered that the spec was not formal enough to show it does the right thing in terms of shadow dom and that it would need to get moved into the relevant spec - pointer events and mouse events.

Hadley: I am finding it hard to engage with finding that it jumps into "how it works" and there is no explainer.

[many ideas of what it could be used for]

David: i've seen discussion - some of it comes down to a browser diffeence - some browsers get the mouse events from the OS and fire them through to the web app. what chrome does is it fires a mouse move per vsync cycle. That's probably a better model - but if you are doing a drawing application you actually want the set of coalesced mouse positions from the whole movement. So if you care about the path, you can get them.

Ken: also for gesture recognition.

Alice: and if you're a game... also some of this info is in the intro - but the text is hard to engage with.

Hadley: this issue made me realize that our trmplate does say "explainer/requirements doc/example code" ...

David: we did change that to explainer (containing user needs and example code)

Alice: in terms of this issue - the spec quality issues may be out of our remit...

Tess: that's the case of a lot of things that come our way...

Alice: i'm not saying we don't do the review...

Hadley: i think editorial is out of scope but if it's difficult to review it should be in scope.

Alice: it took more work - my vote would be to say "i think the API looks fine" - would give feedback that the spec was hard to read and we asked for an explainer but you didn't provide. the spec could be made clearer and provide some example code. The API looks fine though.

Lukasz: the spec has no security & privacy considerations - I'm worried that this would be giving versatile info about the pointer movement - and this ability to track mouse movements without any prompts - there are a lot of research works indicating some possibilities of user tracking based on mouse movements - i'm wondering whether this provides something not provided by old-style API. Should we ask them to fill in the security & privacy questionnaire.

Ken: i think it's fine - if people start using this for tracking this would slow down the whole browser so it could be a performance issue. Maybe there should be a prompt.

[discussion on performance-related issues - slowing down the browser]

Ken: can you write some of these comemnts, lukasz?

Lukasz: how often would the event fire?

Alice: (as david said) it's only chrome thay actually does this coalescing...

David: firefox does not, i'm not sure about pointer events....

Lukasz: i still feel there is a problem with old-style mouse tracking...

Alice: I'm not sure what the privacy issues are ...

Ken: I think it makes sense to ask them to cosndier...

Alice: they did fill in the s&p review - all "no" -

Ken: we could ask the question thay lukasz gave...

Dan: I don't think a "no no no" answer to S&P is appropriate considering the fine-grained info theu are making available.

Hadley: If we are looking at expanding the fingerprinting surface area, we should ask them to consider it themselves, and to put it in the spec so that implementers can take mitigating actions if they want.

Alice: Lukasz, can you file an issue on their repo?

Lukasz: OK, I will.

Alice: i will write a comemnt on the review talking about the spec quality - needs to be clearer.

Peter: also anne's comments about how if the raw/coalesced events would interact with shadow dom.

[meta-discussion on secondary call times

Sangwhan: This was one of the "why is TAG so slow" complaints.

Sangwhan: I need another week on this.

Dan: Will revisit on the 26th.

Lukasz: Asked about privacy/security considerations. Got reply they're waiting for PointerEvents 3 (not entirely sure they intend to tackle it in the e. Are we removing privacy label from the current issue?

Alice: we discussed this - sangwhan and I - an explainer did come in and fleshes [things] out reasonably well. We thought we are done.

Sangwhan: i had issues with the naming.

Alice: that coalesce is a tricky name for non-english-proficient... Spelling bee word. But might not be a frequently used API... I can't think of any good alternative.

Dan: bundled? Doesn't feel like we should block on that though.

Alice: a LGTM with suggestions.

Sangwhan: yes - i'm ok with that but I'd like to be on record about the english-language issue raised. When reading somneone else's code this won't read nicely.

Alice: I will write the feedback.

[consensus to close