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

Clarify the button value for mouse drag #34

Merged
merged 1 commit into from Feb 8, 2016

Conversation

Projects
None yet
3 participants
@mustaqahmed
Copy link
Contributor

commented Feb 2, 2016

The current spec wording suggests that the |button| value indicates "the last button changed" (like MouseEvent). On the other hand, the current Edge behavior suggests that |button| is "the button change that triggered the current event". The latter makes more sense since it makes it easier to differentiate between

  • a pointermove fired through a button activity (chorded button press/release), and
  • a pointermove fired through a non-button change (position, tilt, pressure, etc).

This patch proposes a spec wording change based on the Edge behavior.

Issue #33

@mustaqahmed

This comment has been minimized.

Copy link
Contributor Author

commented Feb 3, 2016

@jacobrossi, please let me know if my proposed changes make the spec clearer or not.

index.html Outdated
@@ -319,26 +319,46 @@
<section>
<h3><dfn>Chorded Button Interactions</dfn></h3>
<div><p>Some pointer devices, such as mouse or pen, support multiple buttons. In the [[!DOM-LEVEL-3-EVENTS]] Mouse Event model, each button press produces a <code>mousedown</code> and <code>mouseup</code> event. To better abstract this hardware difference and simplify cross-device input authoring, Pointer Events do not fire overlapping <code>pointerdown</code> and <code>pointerup</code> events for <a data-lt="Chorded Button Interactions">chorded button presses</a> (depressing an additional button while another button on the pointer device is already depressed).</p>
<p>Instead, chorded button presses can be detected by inspecting changes to the <code>button</code> and <code>buttons</code> properties. The <code>button</code> and <code>buttons</code> properties are inherited from the [[!DOM-LEVEL-3-EVENTS]] <code>MouseEvent</code> interface. In order to facilitate differentiating button state transitions in any pointer event (and not just <code>pointerdown</code> and <code>pointerup</code>), the <code>button</code> property takes on a new value when no mouse buttons are depressed:</p>
<p>Instead, chorded button presses can be detected by inspecting changes to the <code>button</code> and <code>buttons</code> properties. The <code>button</code> and <code>buttons</code> properties are inherited from the [[!DOM-LEVEL-3-EVENTS]] <code>MouseEvent</code> interface with modified semantics and values; see the following sections for details.</p></div>

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Feb 3, 2016

Member

I'd suggest a subtle rewording from

interface with modified semantics and values; see the following sections for details.

to

interface, but with a change in semantics and values, as outlined in this section.

index.html Outdated
@@ -319,26 +319,46 @@
<section>
<h3><dfn>Chorded Button Interactions</dfn></h3>
<div><p>Some pointer devices, such as mouse or pen, support multiple buttons. In the [[!DOM-LEVEL-3-EVENTS]] Mouse Event model, each button press produces a <code>mousedown</code> and <code>mouseup</code> event. To better abstract this hardware difference and simplify cross-device input authoring, Pointer Events do not fire overlapping <code>pointerdown</code> and <code>pointerup</code> events for <a data-lt="Chorded Button Interactions">chorded button presses</a> (depressing an additional button while another button on the pointer device is already depressed).</p>
<p>Instead, chorded button presses can be detected by inspecting changes to the <code>button</code> and <code>buttons</code> properties. The <code>button</code> and <code>buttons</code> properties are inherited from the [[!DOM-LEVEL-3-EVENTS]] <code>MouseEvent</code> interface. In order to facilitate differentiating button state transitions in any pointer event (and not just <code>pointerdown</code> and <code>pointerup</code>), the <code>button</code> property takes on a new value when no mouse buttons are depressed:</p>
<p>Instead, chorded button presses can be detected by inspecting changes to the <code>button</code> and <code>buttons</code> properties. The <code>button</code> and <code>buttons</code> properties are inherited from the [[!DOM-LEVEL-3-EVENTS]] <code>MouseEvent</code> interface with modified semantics and values; see the following sections for details.</p></div>
<section class="note">The modifications to the <code>button</code> and <code>buttons</code> properties apply only when firing pointer events. This specification does not alter the values of <code>button</code> or <code>buttons</code> used when firing mouse events. See [[DOM-LEVEL-3-EVENTS]] for the values when firing mouse events.</section>

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Feb 3, 2016

Member

I'd suggest changing

properties apply only when firing pointer events.

to

properties only apply to pointer events.

Also, I'd turn the following

This specification does not alter the values of button or buttons used when firing mouse events. See [DOM-LEVEL-3-EVENTS] for the values when firing mouse events.

around to

For any <a>compatibility mouse events</a> the value of button and buttons should follow [DOM-LEVEL-3-EVENTS]

index.html Outdated
</section>
<section>
<h3>The <code>button</code> property</h3>
<div><p>In order to facilitate differentiating button state transitions in any pointer event (and not just <code>pointerdown</code> and <code>pointerup</code>), the <code>button</code> property gives the device button whose state-change fired the event.</p></div>

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Feb 3, 2016

Member

In order to facilitate differentiating

perhaps simpler

To differentiate

Also

the button property gives

to

the button property indicates

index.html Outdated
<tr><td>Pen contact with eraser button pressed</td><td>5</td></tr>
</tbody>
</table>
<section class="note">During a mouse drag, the <code>button</code> property in a <code>pointermove</code> event has a value different from the same property in a <code>mousemove</code> event. For example, while moving the mouse with the right button pressed, the <code>pontermove</code> events will have <code>button = -1</code> but the <code>mousemove</code> events will have <code>button = 2</code>.</section>

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Feb 3, 2016

Member

the button property in a pointermove event has a value different from the same property in a mousemove event

perhaps rearrange to

the value of the button property in a pointermove event will be different from that in a mousemove event

and

the pontermove events will have button = -1 but the mousemove events will have button = 2.

perhaps better as

the pontermove events will have a button value of -1, while the mousemove events will have button value of 2.

index.html Outdated
</section>
<section>
<h3>The <code>buttons</code> property</h3>
<div><p>The <code>buttons</code> property gives the current state of the device buttons (same as in <code>MouseEvent</code> but with a bigger set of values).</p></div>

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Feb 3, 2016

Member

same as in MouseEvent but with a bigger set of values

perhaps change to

same as in MouseEvent, but with an expanded set of possible values

index.html Outdated
@@ -364,7 +384,7 @@
<h2>Pointer Event Types</h2>
<section>
<h3>Firing events using the <code>PointerEvent</code> interface</h3>
To <dfn>fire a pointer event name e</dfn> means to <dfn>fire an event named e</dfn> as defined in [[!DOM4]] with an event using the <a>PointerEvent</a> interface whose attributes are set as defined in <a href="#pointerevent-interface"><code>PointerEvent</code> Interface</a>.</p>
To <dfn>fire a pointer event name e</dfn> means to <dfn>fire an event named e</dfn> as defined in [[!DOM4]] with an event using the <a>PointerEvent</a> interface whose attributes are set as defined in <a href="#pointerevent-interface"><code>PointerEvent</code> Interface</a>.

This comment has been minimized.

Copy link
@patrickhlauke

patrickhlauke Feb 3, 2016

Member

for consistency with previous sections, maybe wrap this in a <div><p>...</p></div> as well?

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Feb 3, 2016

...with apologies for possibly bikeshedding some wording there. Apart from that, I think it brings the point we're trying to make across. Would it also be possible to squash this before committing, once we settled on final wordings?

@RByers RByers self-assigned this Feb 5, 2016

@mustaqahmed mustaqahmed force-pushed the mustaqahmed:fix-button-desc branch 2 times, most recently from 1705d72 to 191b8f7 Feb 5, 2016

@mustaqahmed

This comment has been minimized.

Copy link
Contributor Author

commented Feb 5, 2016

Hi Patrick:
Thanks for the careful look. Done with the suggested edits plus squashing, ptal.

index.html Outdated
</section>
</section>
<section>
<h2><dfn>The Primary Pointer</dfn></h2>
<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 active pointers for each pointer type. Only a primary pointer will produce <a>compatibility mouse events</a>. 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>).
<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 active pointers for each pointer type. Only a primary pointer will produce <a>compatibility mouse events</a>. 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
@patrickhlauke

patrickhlauke Feb 5, 2016

Member

stray "." after the closing </div> at the end

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Feb 5, 2016

LGTM (noting that one tiny stray ".")

@RByers RByers assigned patrickhlauke and unassigned RByers Feb 6, 2016

@RByers

This comment has been minimized.

Copy link
Contributor

commented Feb 6, 2016

Thanks for the review @patrickhlauke. I finally made time to take a look and it looks great to me (except for that trailing "." - otherwise I'd merge).

I'm out for a week and a half, Patrick can you please merge this once that last issue is fixed?

@mustaqahmed mustaqahmed force-pushed the mustaqahmed:fix-button-desc branch from 191b8f7 to b51a0f6 Feb 8, 2016

@mustaqahmed

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2016

Done moving the '.' to the para before.

@mustaqahmed mustaqahmed force-pushed the mustaqahmed:fix-button-desc branch from b51a0f6 to 3dc4151 Feb 8, 2016

@mustaqahmed

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2016

Fixed the second '.' outside the para, yikes! Sorry for the oversight!

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Feb 8, 2016

Lovely, thank you 👍

patrickhlauke added a commit that referenced this pull request Feb 8, 2016

Merge pull request #34 from mustaqahmed/fix-button-desc
Clarify the button value for mouse drag, and how it differs from mouse events/dom level 3

@patrickhlauke patrickhlauke merged commit e5cbdde into w3c:gh-pages Feb 8, 2016

@mustaqahmed mustaqahmed deleted the mustaqahmed:fix-button-desc branch Feb 9, 2016

@mustaqahmed mustaqahmed restored the mustaqahmed:fix-button-desc branch Feb 9, 2016

@mustaqahmed mustaqahmed deleted the mustaqahmed:fix-button-desc branch Mar 4, 2016

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