Minutes from Pointer Events WG call 1 September 2021

Dear all,

minutes from today's call are at 
https://www.w3.org/2021/09/01-pointerevents-minutes.html and copied below:

PEW
01 September 2021

Agenda: 
https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20210901T110000

Attendees:  flackr, mustaq, Patrick_H_Lauke, smaug

Chair: Patrick H. Lauke
Scribe: Patrick H. Lauke

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

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



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

Patrick: change since last time is changing "round" to "Math.floor" 
reference

Rob: I think this is good, but we need similar in compat mouse events

Mustaq: should do separately

Rob: can do, but then we should cross-reference in this bit ("similar to 
compat mouse events...")

[discussion on how we should say the same in compat mouse events or not]

Patrick: fundamentally, wonder if we can extract the whole discussion on 
flooring to a new top-level section (similar to our section 12 
Converting tiltX/tiltY...) and then cross-reference from both those 
places to this

Patrick: I'd suggest merging THIS PR now (as it does other things that 
we want to retain), and doing a follow-up PR that does the abstraction 
to a new section

ACTION: create PR for a new section that abstracts/generalises 
coordinate conversion and adds cross-references



# Notes with normative (SHOULD/MUST) statements 
https://github.com/w3c/pointerevents/issues/405
Patrick: let's go through these one by one, should hopefully not take 
too long...

https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid

[discussion of the weird "conditional MUST" and whether we want the 
whole note normative]

Mustaq: suggest adding the second requirement to the normative text 
before the note

Patrick: "This identifier MUST be unique from all other active pointers 
in the top-level browsing context (as defined by [HTML]) at the time"

add to this sentence: ", and the identifier MUST NOT be influence by any 
other top-level browsing context"

Rob: I think, from the last bit of the note, the concern is tracking 
across pages if the id is the same

Patrick: so with the suggested addition above, we can then remove the 
problematic "However ..." onwards from the note and leave it at that

in addition, changing that "starting from 1" to "starting from 0" (since 
we moved the reserved value from 0 to -1 ages ago)

first note on 
https://w3c.github.io/pointerevents/#dom-pointerevent-getpredictedevents

my take: that whole note should be normative

<mustaq> Correction for above: "ages ago" -> "few months ago" :)

Rob: that seems right

"few months ago" is aeons in internet years :)

Olli: we can remove the "Implementations SHOULD provide both" as it's 
not needed

Patrick: yes it's a truism, as those attributes are part of the spec

<mustaq> https://github.com/w3c/pointerevents/issues/321

<mustaq> Past discussion about default values: 
https://github.com/w3c/pointerevents/issues/320

Patrick: so ripping out the whole second sentence ("When an 
untrusted...") and change the WebIDL to have "=0" for 
tiltx/tilty/azimuthAngle/altitudeAngle?

Rob: yes, I think so

Patrick: I quite like the opening sentence that sets the scene in that 
note, that explains where altitude/azimuth came from (touch events)

Patrick: maybe ripping this out and moving it to the start of section 12 
Converting ...

Mustaq: but the last sentence about Math.round is important

Patrick: can't move that sentence to section 12 as the whole section is 
non-normative

Patrick: examples are definitely non-normative per the preamble. the 
example code for conversion is what we didn't want normative

so we could make section 12 normative, that still keeps the example code 
non-normative

and we can then move Math.round sentence to the start of this

Mustaq: even the calculation process should be normative, the output 
should be the same

Olli: agree

Patrick: but examples are non-normative by definition

Rob: we could make this a normative algorithm

Patrick: so should we change "The following basic code provides an 
initial suggested approach for converting these values." to something 
like "User agents MUST use the following algorithm for converting these 
values"

Rob: yes

Olli: looking for other specs with similar algorithms

Rob: web animations has heavy ones

<flackr> as an example, 
https://www.w3.org/TR/web-animations-1/#calculating-the-active-time

Patrick: so to recap, make section 12 normative, move first sentence of 
the note (that sets the scene) to start of section 12, change the 
sentence to say this is the algorithm

Patrick: i might make a PR for these two already. meanwhile if you want 
to look at the remaining ones, leave a comment in thread

ACTION: make PR for first two notes mentioned in #405

Patrick: sorry, overran, but this was good ... as painful as this 
discussion on notes and SHOULD/MUST is, it's cleaning up some things 
that have been lingering in the spec text for a while. speak to you all 
in 2 weeks' time



Summary of action items

* create PR for a new section that abstracts/generalises coordinate 
conversion and adds cross-references

* make PR for first two notes mentioned in #405


-- 
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Wednesday, 1 September 2021 16:08:50 UTC