Rewrite of primary pointer section #53
Conversation
|
This LGTM. I also read over the compatibility mouse events section to ensure it was correct given these changes (definitely can't fire any mouse events for these weird non-primary mouse pointers), and it looks good. |
|
Just commenting on the precise wording though - I think we may want to make a couple tweaks... |
| @@ -364,15 +364,17 @@ | |||
| <h3>Determining the primary pointer</h3> | |||
| <div>When firing a pointer event, a pointer is considered primary if: | |||
| <ul> | |||
| <li>The pointer represents a mouse device.</li> | |||
| <li>The pointer represents a primary mouse input.</li> | |||
There was a problem hiding this comment.
Seems like we can simplify this whole section now that the mouse, touch and stylus paragraphs are mostly redundant. See below.
testing on Surface 3 with Pen and Edge, the pen is primary as soon as it's recognized/hovering. so quite right, i think this isn't correct - but that's a separate issue (which i'll file later today) |
agree - perhaps with link/pointer to the glossary definition of "active pointer" - this is the simplest amendment (which then can help simplify the entire prose for this section, i may actually work on this as one combined PR, but open a separate issue for clarity) |
patrickhlauke
changed the title
|
Pushed a separate commit to address both #54 and #49 - drastically simplifies the definition and brings it in line with reality of implementation. /cc @jacobrossi @RByers |
| </section> | ||
| <div><p>In a multi-pointer (e.g. multi-touch) scenario, the <a href="#widl-PointerEvent-isPrimary"><code>isPrimary</code></a> property is used to identify a master pointer amongst the set of <a data-lt="active pointer">active pointers</a> for each pointer type.</p></div> | ||
| <ul> | ||
| <li>At any given time, there can only ever be exactly one primary pointer for each pointer type.</li> |
There was a problem hiding this comment.
Does
"...there can be at most one primary pointer..."
make it clearer? The phrase "can ever be exactly one" seems to exclude the following cases of no primary "touch" pointer:
- when there's no active touches, and
- when two fingers touch the screen in sequence, then the first one is removed.
There was a problem hiding this comment.
ah, good call. yes, that would make it clearer and more correct. i'll push an update
|
LGTM, thanks Patrick. |
Due to the addition of multi-mouse scenario, the explanation of what a primary pointer is can be condensed/simplified, rather than being split into "primary mouse"/"primary touch"/"primary pointer". This change also corrects the previously erroneous description of when touch/pen pointers become primary - as hovered pen (and presumably, if supported by hardware, hovered touch) is also primary, it's not really related to `pointermove` but rather to which active pointer for that type came first.
|
LGTM, thanks! |
|
I squashed your two commits and merged them. I hope that's what you intended (otherwise I can easily undo it). |
|
Yes i was relying on GitHub's new autosquashing feature :) |
This generalises the treatment of mouse inputs to allow for the possibility of systems that support more than one simultaneous and independent mouse device, while at the same time clarifying that currently most (all?) operating systems/user agents don't have a concept of multiple mouse pointers.
It future-proofs the spec while also reflecting reality.
Closes #49