Advice to use :hover on touchscreens may not be optimal about webfundamentals HOT 9 CLOSED

Reasonable perspective. @gauntface what do you think?

from webfundamentals.

Also, annoyingly, :hover styles are sticky on iOS: http://stackoverflow.com/questions/17233804/ , mdo/wtf-html-css#31

from webfundamentals.

They're sticky just about everywhere.

from webfundamentals.

This is a really important point which I haven't encountered before.

At the moment I'm thinking of recommending:

1.) Expect hover pseudo classes to apply after a click and stick around until another element is clicked. To hint to the user an element is clickable, set a cursor with: cursor: pointer; and avoid any styles you wouldn't want to linger (i.e. a background-color change).

2.) Setting a focus pseudo class will stick after an element is clicked (similar to hover), Safari will only show focus states on some elements. (Normal disclaimer of only remove outline if you intend to apply your own styles etc.)

3.) Setting an active state will apply when a user touches an element, however iOS does not apply the active state by default, meaning that disabling the -webkit-tap-highlight-color will result in no touch feedback for iOS users.

To add support for the active state on iOS you need to add a touchstart event listener to your elements. Don't add the touchstart event listener to the document body as this will affect performance, it's much safer to the listeners to the elements themselves..

How does this sound? I'm very close to suggesting not doing touch response on any level since the chances of getting unwanted results is fairly high.

@pp-koch I originally had a section for using touch events to handle touch response because the 300ms delay was fairly damning, but that doesn't seem to be much of a problem across the browsers I've tested against iOS, Chrome, FF, IE10 (WP). iOS is the only odd one out for a lot of this behavior.

from webfundamentals.

@RByers may have thought about use of :hover on touchscreens before. Rick, what do you think is the best practice here?

from webfundamentals.

That guidance sounds reasonable. I think we're in a pretty good state in "modern" browsers (mostly consistent and rational) but as soon as we need to worry about Safari it gets tough. Maybe we should be building/advocating a single library for polyfilling the improvements other browsers have made here.

Rule #1 in any site designed to be used on mobile is to disable the click delay (set a mobile viewport or use touch-action: manipulation, and worst case rely on a hack like FastClick for old-school browsers like Safari). So if we're trying to bypass the click delay we've already lost. So when a user taps on an element, it will get :active and :hover immediately after the touchend.

This is potentially still a delay from what the user might want (set immediately on touchstart), which is entirely a UX tradeoff - not a technical one, but unfortunately not one we let the app easily change. We add a 'show press' delay (50ms I think) to avoid things flickering active/hover when scrolled. Most android apps do the same thing. So I don't think we want to blanket suggest that people should show touch affordances on touchstart (it looks terrible when scrolling). But it isn't unreasonable to suggest people may want to add their own fast-press when they know scrolling is impossible or unlikely. Ideally I think the browser would be smart here and show them immediately when scrolling isn't possible - but there's debate about this, see https://codereview.chromium.org/163933002/.

from webfundamentals.

I tend to agree with @gauntface 's summary, though I tend to pooh-pooh :active because it's not very well supported. I must admit I tested :focus only in form fields, and not on other elements. I haven't tested the performance implications of touchstart on the document.body, either, but it sounds logical.

I tend to be careful of advising everyone to remove the 300ms delay because it could lead to turning off zooming, which is Evil. Instead, I would say that they should use width=device-width (duh) and the delay will more-or-less take care of itself. touch-action: manipulation would also help, but is only available on IE (and Chrome?).

CSS selector support: http://quirksmode.org/css/selectors/mobile.html
300ms delay removal: http://www.quirksmode.org/blog/archives/2014/04/suppressing_the.html

from webfundamentals.

@pp-koch on that point of not recommending :active state, do you think it's best to advice overriding the -webkit-tap-highlight-color if you want to do anything on touch?

from webfundamentals.

Fixed by 931ad9e

from webfundamentals.