Notes with normative (SHOULD/MUST) statements

[patrickhlauke]

all authoring guidelines, diagrams, examples, and notes in this specification are non-normative

however, we have a few instances of notes that contain MAY, SHOULD, SHOULD NOT, MUST.

• https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid > Move elements of pointerId informative note to normative text #411
• first note in https://w3c.github.io/pointerevents/#dom-pointerevent-getpredictedevents > Make "Converting..." section normative #410
• second note in https://w3c.github.io/pointerevents/#coalesced-events > Move first part of the note about dispatched event order into normative text #412
• second note in https://w3c.github.io/pointerevents/#mapping-for-devices-that-do-not-support-hover > Make note about UAs not firing compat events if they support touch events normative #413
• note in https://w3c.github.io/pointerevents/#chorded-button-interactions - make the note normative (about compat events and how the button/buttons should follow UIEVENTS) > Make note about buttons/buttons and compat events normative #414
• 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? Remove should from boundary events note and move to normative must. #419
• first note in https://w3c.github.io/pointerevents/#the-touch-action-css-property right at the end contains a "should" - i'd reword that to avoid the word altogether > Remove may/should from note about complex gestures #415
• 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? Make fact that click/contextmenu are not compat mouse events normative #418
• second note in https://w3c.github.io/pointerevents/#dfn-active-pointer - i'd make the note normative text (and change "id" to "pointerId"). however, this is in the glossary, which by definition is non-normative. should this be moved somewhere else / into the normative text/interface definition? also, what does that second note actually try to say? Remove redundant (and now wrong) note about active pointer id #417
• note in https://w3c.github.io/pointerevents/#attributes-and-default-actions "the values of those (inherited) attributes in PointerEvents must be null to encourage the use of the standardized alternates" - suggest rewording this, as it's more of a strong suggestion than something we can/want to normatively demand > Reword legacy properties note to remove the "must" #416

We can either decide that these can be changed into "soft" requirements (and either lowercase or avoid those BCP14 keywords), or we must turn those notes into normative prose.

[bmathwig]

We (Microsoft Edge) would be supportive of adjusting the wording of the pointerId note. Specifically, the pen/stylus as an 'Active Pointer' even when the pen is moved away from the digitizer and requiring it to be considered the same 'Active Pointer' on re-entry into the proximity space of the digitizer.

This would enable a scenario where a User Agent can use the same pointerId for the same physical pen for multi-pen experiences.

[patrickhlauke]

@bmathwig I assume you mean turning the note https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid into normative prose (i.e. removing the note markup around it). Which I think is appropriate/acceptable (don't think we say anything majorly controversial in that section, and we do have the MUST there which needs to be dealt with, and making the whole section normative does that.

[patrickhlauke]

adding my takes here for each of the mentioned notes:

• https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid make the entire note normative text (so that the "user agents MUST ensure that the pointerId that is assigned remains the same" part becomes normative)
• https://w3c.github.io/pointerevents/#dom-pointerevent-getpredictedevents make the entire note normative text (so that all the various SHOULD clauses become normative too)
• second note in https://w3c.github.io/pointerevents/#coalesced-events - i'd make the text up to "Here's an example..." normative. then keep the example and the table in an informative note.
• second note in https://w3c.github.io/pointerevents/#mapping-for-devices-that-do-not-support-hover - i'd make the note normative (making the SHOULD NOT normative)

[patrickhlauke]

[edit: moved to the thread starter]

[mustaqahmed]

... where a User Agent can use the same pointerId for the same physical pen for multi-pen experiences

Thanks @bmathwig, yes that's a useful use-case we need to support. IIRC we faced issues with detecting the "same physical pen" in the past. Moving a pen off the digitizer range then bringing in a different pen made the second pen indistinguishable from the first one. Didn't investigate if it was caused by a limitation in the hardware or the device driver or the OS (FYI it was several years ago, we used Windows Surface). If a low-level unique pen-id is available these days, that's all we need.

Also note that we don't have to maintain the removed pen as an "active pointer" to support this use case. In fact, maintaining a pen as "forever active" like this would be problematic when the pen has no chance of coming back (say its battery died): if the "dead" pen was the first pen seen by the digitizer, by definition it would remain the primary pointer forever and a replacement pen won't ever produce compatibility mouse events (as a non-primary device of type "pen").

[patrickhlauke]

we had some initial discussions on the first two notes in today's meeting - will do a PR (or two separate PRs even) specifically for those notes, bat them away individually rather than as a single monolithic PR

https://www.w3.org/2021/09/01-pointerevents-minutes.html#t02

[patrickhlauke]

"second note in https://w3c.github.io/pointerevents/#dfn-active-pointer" discussed in meeting today, agreed that the note is now redundant (and wrong). will remove it

[patrickhlauke]

from today's meeting:

• @flackr to draft a PR for the note regarding pointer capture target override https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface
• @patrickhlauke to draft PR for first note in https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events - making first paragraph normative, hardening definition of default actions and canceling to say that canceling a pointer event will prevent ALL compat mouse events (not just "some")

[patrickhlauke]

@flackr reminder of this

draft a PR for the note regarding pointer capture target override https://w3c.github.io/pointerevents/#firing-events-using-the-pointerevent-interface