Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite of primary pointer section #53

Merged
merged 2 commits into from Apr 29, 2016

Conversation

@patrickhlauke
Copy link
Member

commented Apr 22, 2016

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

@RByers

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2016

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.

@RByers

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2016

Just commenting on the precise wording though - I think we may want to make a couple tweaks...

index.html Outdated
@@ -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>

This comment has been minimized.

Copy link
@RByers

RByers Apr 25, 2016

Contributor

Seems like we can simplify this whole section now that the mouse, touch and stylus paragraphs are mostly redundant. See below.

index.html Outdated
<li>The pointer represents a primary touch input.</li>
<li>The pointer represents a primary pen input.</li>
</ul>
</div>
<dl>
<dt>primary mouse input</dt><dd>A pointer representing mouse input is considered the <i>primary mouse input</i> if it dispatched any pointer events (such as <code>pointerdown</code> or <code>pointermove</code>) when no other active pointers representing a mouse input existed. However, see the note about <a href="#multiple-mouse-inputs">multiple mouse inputs</a>.</dd>

This comment has been minimized.

Copy link
@RByers

RByers Apr 25, 2016

Contributor

I think this (and the existing touch/pen sections below when considering hover-capable pointers) isn't quite right. Eg. consider the case of two mice (or pens) both hovering without either being active. One needs to be primary, right? What happens in Edge today when a pen first becomes visibly by the digitizer - does it have isPrimary=true from the first pointermove, or only after the first pointerdown event?

I think the essential properties are that:

  • At any given time exactly one pointer of each type is considered primary
  • When the first pointer of a given type becomes active, that pointer also becomes the primary pointer
@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 2016

@RByers

What happens in Edge today when a pen first becomes visibly by the digitizer - does it have isPrimary=true from the first pointermove, or only after the first pointerdown event?

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)

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 2016

When the first pointer of a given type becomes active, that pointer also becomes the primary pointer

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 patrickhlauke changed the title clarification why mouse is always primary Rewrite of primary pointer section Apr 25, 2016

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 2016

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

index.html Outdated
</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>

This comment has been minimized.

Copy link
@mustaqahmed

mustaqahmed Apr 28, 2016

Contributor

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.

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Apr 28, 2016

Author Member

ah, good call. yes, that would make it clearer and more correct. i'll push an update

index.html Outdated
<li>The first pointer to become active for a particular pointer type (e.g. the first finger to touch the screen in a multi-touch interaction) becomes the primary pointer for that pointer type.</li>
<li>Only a primary pointer will produce <a>compatibility mouse events</a>.</li>
</ul>
<div class="note">Authors who desire single-pointer interaction can achieve this by ignoring non-primary pointers (however, see the note below on <a href="#multiple-primary-pointers">multiple primary pointers</a>).</p></div>

This comment has been minimized.

Copy link
@mustaqahmed

mustaqahmed Apr 28, 2016

Contributor

Nit: Is there a way to avoid 5 Notes in a row? E.g. by combining 1 & 2, and/or dropping 3?

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Apr 28, 2016

Author Member

3 could be added part of the second bullet above ("Only a primary pointer will product..."). that should lighten this up a bit. 1 & 2 are not directly related (one is about multiple pointers of the same type, the other about different pointer types and their primary pointers), so i'd leave them separate.

index.html Outdated
<ul>
<li>At any given time, there can only ever be at most one primary pointer for each pointer type.</li>
<li>The first pointer to become active for a particular pointer type (e.g. the first finger to touch the screen in a multi-touch interaction) becomes the primary pointer for that pointer type.</li>
<li>Only a primary pointer will produce <a>compatibility mouse events</a>. In the case where there are multiple <a href="#the-primary-pointer">primary pointers</a>, these pointers will all produce <a>compatibility mouse events</a></li>

This comment has been minimized.

Copy link
@mustaqahmed

mustaqahmed Apr 29, 2016

Contributor

We are missing a '.' at the end.

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Apr 29, 2016

Author Member

good spot. fixed

@mustaqahmed

This comment has been minimized.

Copy link
Contributor

commented Apr 29, 2016

LGTM, thanks Patrick.

Simplification and correction of primary pointer section
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.
@RByers

This comment has been minimized.

Copy link
Contributor

commented Apr 29, 2016

LGTM, thanks!

@RByers RByers merged commit 84de292 into w3c:gh-pages Apr 29, 2016

@RByers

This comment has been minimized.

Copy link
Contributor

commented Apr 29, 2016

I squashed your two commits and merged them. I hope that's what you intended (otherwise I can easily undo it).

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

commented Apr 29, 2016

Yes i was relying on GitHub's new autosquashing feature :)

@patrickhlauke patrickhlauke deleted the patrickhlauke:primary-mouse-clarification branch Mar 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.