Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
This repository was archived by the owner on Jul 9, 2024. It is now read-only.

note about avoiding conditional "touch OR mouse/keyboard" event handling #72

Merged
merged 1 commit into from
Aug 2, 2016
Merged

note about avoiding conditional "touch OR mouse/keyboard" event handling #72

merged 1 commit into from
Aug 2, 2016

Conversation

patrickhlauke
Copy link
Member

Closes #71

@scottgonzalez
Copy link
Member

Looks good.

@patrickhlauke
Copy link
Member Author

@RByers to review - this is admittedly a very rough first draft so feel free to rip it apart :)
note i added a reference to InputDeviceCapabilities as well (unsure if that's a done thing since it's only a draft community group report)

@patrickhlauke
Copy link
Member Author

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
Copy link
Contributor

@RByers RByers Aug 2, 2016

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 ;-)

@RByers
Copy link
Contributor

RByers commented Aug 2, 2016

Looks great, thanks! Just a couple small suggestions.

@patrickhlauke
Copy link
Member Author

force-pushed an update. better?

// concurrent "touch AND mouse/keyboard" event binding

// set up event listeners for touch
target.addEventListener('touchend', ...);
Copy link
Contributor

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?

Copy link
Member Author

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)

Copy link
Member Author

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 :)

Copy link
Contributor

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.

@RByers
Copy link
Contributor

RByers commented Aug 2, 2016

LGTM with possible nit (your choice) - feel free to merge.

@patrickhlauke patrickhlauke merged commit 02e3731 into w3c:gh-pages Aug 2, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.