– DRAFT –
PEWG

Expand note about preventing compatibility mouse events https://github.com/w3c/pointerevents/pull/403

Patrick: see additional comment here after our call two weeks ago https://github.com/w3c/pointerevents/pull/403#issuecomment-892968317

Olli: i like that it's a note, because it's normative in the DOM spec, not in our spec

Patrick: ah yes, PE isn't the one making it "normative". i can rationalise that

Rob: agree

Patrick: happy to merge then?

Patrick: note that while i kept the DOM part non-normative, i made the preceding two paragraphs normative - see https://github.com/w3c/pointerevents/pull/403/files

Not hearing any objections. Merging.

Add note about rounding coordinates for click, auxclick, contextmenu https://github.com/w3c/pointerevents/pull/404

Patrick: had this comment in agenda: "the fact that normatively PE don't say that coordinates should be double (currently only makes a non-normative reference to the CSSOM extension) is leading to a lot of ifs and buts. wonder if instead PE should/can just say that they must be double?"

Patrick: issue is: do we want to redefine coords ourselves? can we? we were fine handwaving before in a non-normative note, but now we're paying the price. does Firefox use double?

Olli: no

Rob: from my testing, only Chrome uses double for PEs

Patrick: is this something that PE wants to even tackle/explain? in essence it's a problem, but only because Chrome decided to apply CSSOM's double idea for coordinates, but spec doesn't mandate this

[discussion on how WebIDL spec defines how conversions should happen?]

["rounding towards zero"]

<smaug> https://heycam.github.io/webidl/#es-long

<smaug> https://heycam.github.io/webidl/#abstract-opdef-integerpart

Rob: ah it's flooring the absolute, which is why it leans towards zero

<mustaq> Chrome uses std::floor, for which -2.7 becomes -3

Mustaq: sticking to WebIDL makes sense

Patrick: are we concerned that this is a W3C Editor's Draft?

Olli: I think it's moving soon / will be living standard

Patrick: https://github.com/w3c/pointerevents/pull/404/files

<flackr> https://bugs.chromium.org/p/chromium/issues/detail?id=1166853

Patrick: concerned that we say "there are additional normative requirements" in the initial non-normative note. Then again, the section it points TO is normative.

Mustaq: so for this PR, we can just change the "MUST round the various coordinate properties" to "MUST convert to long"

Olli: that opens up too many web compat issues. should really say how, e.g. "round down"

wonder if IDL spec, or ECMAScript, have something official that defines this conversion

Rob: couldn't we call this out in the compatibility mapping for mouse events

have a section in there to specify if you have different precision, use floor

<flackr> https://jsbin.com/sagenev/edit?html,js,output

we have same behaviour of rounding for mouse compat events

<smaug> https://tc39.es/ecma262/#eqn-floor

Patrick: so i'd suggest i have a stab at changing that sentence with the "round" to actually say browsers should floor, link to ECMAScript, then we can see what that looks like for next meeting (or comment earlier).

Rob: and then after that we can discuss how we want to say the same thing for compat mouse events

<mustaq> Sounds good to me.

Action: Patrick to tweak PR #404 to change "round" to reference to floor/ECMAScript

Notes with normative (SHOULD/MUST) statements https://github.com/w3c/pointerevents/issues/405

Patrick: not to do lengthy discussion now, but if you could all please have a look and ponder. are there notes that should actually be normative? and in ones that should remain notes, should we change/soften the language to not use MUST/SHOULD?

Action: group to review issue #405 and add comments/thoughts

Patrick: thank you all, we'll adjurn for today. See you all in 2 weeks' time.