Add the class .no-touch to all :hovers in style.css

[vasilisvg]

iOs triggers the mouseover event on the first touch when something changes. This happens even with simple changes like a new color or removal of an underline. The click-event only fires the second time you touch.

This is easy to solve, if modernizr is included, by adding the class .no-touch to each :hover rule. In style.css there are two occurences of a:hover, one on line 19 and one on 21. They would look like this:

.no-touch a:hover { color: #06e; }
.no-touch a:hover, a:active { outline: 0; }

[necolas]

We're trying to avoid modernizr/javascript dependencies in the CSS.

The code, as is, will kill hover states in environments where JS has not been executed.

This issue might be worth raising and discussing against the Mobile H5BP repo which is tailored specifically to mobile web apps.

[nimbupani]

Perhaps we should use a way to revert the a:hover effect when Modernizr is included?

[vasilisvg]

Reverting :hover is much harder than not setting it, especially when multiple declarations are set. I tend to agree that there shouldn't be too many modernizr dependencies, if any, but this is actually a pretty big usability issue in many web applications. I'm not sure if this is a mobile only issue, I think it is an input method issue. So if we could come up with a CSS only solution that would be great.

The issue that this code will kill hover states could be solved with yet an extra modernizr dependency:

.no-touch a:hover,
.no-js a:hover { color: #06e; }
.no-touch a:hover,
.no-js a:hover, a:active { outline: 0; }

If it's too much maybe this issue could be mentioned in a comment in the documented CSS file.

[necolas]

This sounds more like an issue with how touch devices choose to work. If you're looking to reproduce a native-like experience with a web app, we have the mobile BP...personally, I'm not convinced the proposals so far should be included in this repo. It makes basic link state styles too dependent on the HTML and JS libs.

[vasilisvg]

You are probably right, necolas, this solution makes a rather trivial interaction dependent on a specific part of a library. This solution should not be part of everybody's default setup. Although I do believe that a different solution (if it exists) or at least a mention of the problem would be in place.

[nimbupani]

@vasllisvg could you write it up on the Make it Better section of the wiki?

[vasilisvg]

Created a gist with an explanation and created a link to this gist from the CSS section of the Make It Better section of the wiki.

[nimbupani]

Thanks!!

[imme-emosol]

Perhaps useful for someone, vim rewrite/substitute commands:

:%s/^([\t ]*)(.{-}):hover/\1.no-touch \2:hover/gc 

or

:%s/^([\t ]*)(.{-}):hover/\1.no-touch \2:hover ,\r\1.no-js \2:hover/gc 

[roblarsen]

(this is one of my pet issues, so forgive the info bomb)

FWIW touch/no-touch are gone from Modernizr. They've been replaced by touchevents, which is more descriptive of the test they're using. Additionally, testing for touch events isn't actually a reliable test for whether or not a machine can hover (or has a mouse or a pen/stylus or whatever binary people are searching for.) There are hundreds of millions of devices that can do both touch and hover (every Galaxy note, for example.)

I recommend taking a look at https://www.youtube.com/watch?v=wwffqMAS8K8

A better solution to the problem outlined in the original issue would Fastclick https://github.com/ftlabs/fastclick or pointer events (with https://github.com/jquery/PEP )