Advice to use :hover on touchscreens may not be optimal #25
Comments
|
Reasonable perspective. @gauntface what do you think? |
|
Also, annoyingly, |
|
They're sticky just about everywhere. |
|
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. |
|
@RByers may have thought about use of :hover on touchscreens before. Rick, what do you think is the best practice here? |
|
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/. |
|
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 |
|
@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? |
|
Fixed by 931ad9e |
# This is the 1st commit message: Adding start of Workbox v3 alpha docs # This is the commit message #2: Adding v3 alpha # This is the commit message #3: Adding configuration guide # This is the commit message #4: Adding workbox-precaching and fixing nested parameters # This is the commit message #5: Setting up namespaced docs on WF # This is the commit message #6: Adding ref and module docs for precaching # This is the commit message #7: Adding ref and module docs for precaching # This is the commit message #8: Routing Docs and module guide # This is the commit message #9: Routing Docs and module guide # This is the commit message #10: Adding workbox-cache-expiration guide and reference docs # This is the commit message #11: Adding routing docs # This is the commit message #12: Changing menu name # This is the commit message #13: Adding ability to use custom project yaml # This is the commit message #14: Adding workbox pages # This is the commit message #15: Getting it to work on devsite staging # This is the commit message #16: Adding some headings instead of sections but need to stage # This is the commit message #17: Moving to heading # This is the commit message #18: Adding heading support for navigation # This is the commit message #19: Adding contributor list # This is the commit message #20: Adding more content for docs # This is the commit message #21: Adding in company logos # This is the commit message #22: Adding in company logos # This is the commit message #23: Adding logos # This is the commit message #24: Adding some fixes for left nav # This is the commit message #25: Renaming strategies # This is the commit message #26: Fixng ref doc bug and add missing module pages # This is the commit message #27: Adding Guides etc
https://developers.google.com/web/fundamentals/documentation/user-input/touch-input/activestates/index
What I'm missing here is a mention that :hover styles will only be applied after the click event, and thus after the 300ms delay. If I'd do a bgcolor change myself I think I'd do it with JS and touchstart - maybe. Touchscreen CSS hover is a bit janky for this purpose.
The text was updated successfully, but these errors were encountered: