-
Notifications
You must be signed in to change notification settings - Fork 20
note about avoiding conditional "touch OR mouse/keyboard" event handling #72
note about avoiding conditional "touch OR mouse/keyboard" event handling #72
Conversation
Looks good. |
@RByers to review - this is admittedly a very rough first draft so feel free to rip it apart :) |
cheers @scottgonzalez ... lightning fast there :) |
<section class="note"> | ||
<p>Even if a user agent supports Touch Events, this does not necessarily mean that a touchscreen is the only input mechanism available to users. Particularly in the case of touch-enabled laptops, or traditional "touch only" devices (such as phones and tablets) with paired external input devices, users may use the touchscreen in conjunction with a trackpad, mouse or keyboard. For this reason, developers should avoid binding event listeners with "either touch or mouse/keyboard" conditional code, as this results in sites/application that become touch-exclusive, preventing users from being able to use any other input mechanism.</p> | ||
<pre class="example"><code> | ||
// conditional "touch OR mouse/keyboard" event binding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: add a comment like "WARNING: Don't do this, many devices support both touch and mouse". Copy/paste (without reading spec text) is far too common ;-)
Looks great, thanks! Just a couple small suggestions. |
force-pushed an update. better? |
// concurrent "touch AND mouse/keyboard" event binding | ||
|
||
// set up event listeners for touch | ||
target.addEventListener('touchend', ...); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: show an inline handler that calls preventDefault?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
avoided doing that, because later i talk about both doing preventDefault AND the possibility of using InputDeviceCapabilities, so i'd possibly need to do both (unless i reword it slightly, hmmm)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, what the heck, made the change :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks looks good! Support for InputDeviceCapabilities is only Chrome at the moment, so this is probably the better choice in most situations.
LGTM with possible nit (your choice) - feel free to merge. |
Closes #71