– DRAFT –
PEWG

Tweaks to coalesced/predicted events section https://github.com/w3c/pointerevents/pull/395

Patrick: i can make the change for "smaller than or equal" / "greater than or equal". The sanitisation one is trickier.

Rob: [paraphrasing] it gets complex if we expect to sanitize all passed untrusted events, with getters/setters/accessors, that can be observable

[discussing whether we want to have sanitisation or not - causes complications, and we already specifically say that other parts of the list management (e.g. monotonically ordered etc) only applies to trusted events]

Patrick: so is the minimum viable change here to add "trusted" to the start of 10.3 ?

Rob: yes

Patrick: I can make that change

mustaq: do we need to say anything about trusted events in other places, like 4.1.2 for instance which defines constraints for primary pointer?

mustaq: maybe we can do trusted here, and open a new issue to look at any other constraints to specify that it needs to be just for trusted

Patrick: what about the one instance where we ask UAs to sanitize tiltX/tiltY/azimuthAngle/altitudeAngle?

Rob: this is slightly different, as it backfills based on the dictionary/definition. doesn't do processing/sanitisation

mustaq: we also don't sanitise if developer has provided any value. this is only when they left them out completely

Patrick: yes, can rationalise that

Action: make the discussed changes and merge

Remove note about movementX/movementY and coalesced events https://github.com/w3c/pointerevents/pull/397

Patrick: I admit i can live with it as it is now, but it just strikes me that we say "this spec doesn't want to define this" and then goes on to strongly suggest what should happen

mustaq: agree with Patrick, but would be nice to link to PointerLock as reference

<mustaq> https://w3c.github.io/pointerlock/#extensions-to-the-mouseevent-interface

Rob: don't mind if we accept PR as is

mustaq: concerned that if we remove this, it's gone/not mentioned anywhere

Rob: in fairness, it's not about the non-coalesced events, but it's about the top level event itself

Rob: pointerlock spec can then refence the PE coalesced spec

Action: merge the PR

Should "click", "dblclick" and "contextmenu" events be PointerEvents? https://github.com/w3c/pointerevents/issues/100

Patrick: we mentioned click etc here https://w3c.github.io/pointerevents/#the-click-auxclick-and-contextmenu-events

Patrick: based on that, as developer, reading that click etc are PEs, i would then expect coordinates to have same precision

<mustaq> https://drafts.csswg.org/cssom-view/#extensions-to-the-mouseevent-interface

<mustaq> This is where they are re-defined as real numbers.

<mustaq> "The CCSOM View spec extensions don't apply to click, auxclick..."

Rob: looks like UIEvents specifies they're integers. if you look at 4.2.12 we reference UIEvents, so maybe we need to add a note "as the UIEvents spec defines these as integers...UAs MUST round these. even though type changes, precision hasn't."

mustaq: not even a note, and actual normative text

Action: Patrick to write additional text to define that click,aux,contextmenu despite being PEs must round their coordinates as per UIEvents spec

HTML monkeypatching: initiate the drag-and-drop operation definition https://github.com/w3c/pointerevents/issues/384

mustaq: forgot about this one

Patrick: don't worry, look at it for next time

Action: mustaq to review issue #384 and propose a change/addition

Patrick: just wanted to mention to that issues labelled v3 are slowly but steadily decreasing https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3

Patrick: some of those issues are likely hairy problems...but for now, I think it's good that we're making visible progress. I'd say unless there are other burning issues, we'll leave it at that and reconvene in 2 weeks' time.