Bug #2837
closedInterface Issues on Touch Devices
0%
Description
A number of issues on touch devices have been reported. Some are related to :hover and others are separate. I'm introducing this bug as a kind of parent for the other issues and a place to get some general ideas down. Separate tickets will be created for specific issues.
One of the issues is with how phone and tablet devices treat elements that have been styled with the CSS pseudo selector :hover. On iOS most of the time when something has :hover, the OS simulates the hover. However depending on what the hover is applied to it reacts differently.
The issue we're facing is related to links that involve hover. If the hover is directly applied to the anchor, a:hover{} then it works fine and just briefly flashes the hover state before proceeding to the link. It seems to also work if the hover is applied to a containing element, p:hover a{}.
If however the :hover rule changes the visibility property, then the behavior changes. Usually this is done where some content is not visible then when you hover over a containing element content inside becomes visible and links appear. In the best case the first click shows the hidden content and the second click leads you to it. However, it seems to be our experience on the Commons that sometimes the second click doesn't lead you anywhere on the link.
For some articles that discuss the problem read these:
http://www.nczonline.net/blog/2012/07/05/ios-has-a-hover-problem/
http://www.prowebdesign.ro/how-to-deal-with-hover-on-touch-screen-devices/
- Remove all :hover from CSS that shows elements with the visible or display properties. You could progressively enhance by using JavaScript to add that back in on no-touch devices
- Write some JavaScript that makes the links work on touch devices.
We may choose to use different directions for different parts of the site. I don't claim to be an authority on this and open the topic for discussion.
Related issues
Updated by Chris Stein about 11 years ago
When looking to solve this issue there are a few different things we might try out. I haven't had time to vet them yet so I'm putting some out there for consideration.
A simple one involves just removing hover both from CSS and JS events. In some cases, like BP Docs #2838 this might be fine but for others like the issue with the admin bar #2733, that might not be so feasible.
Another solution would involve adding Modernizr to the mix and then we can add .no-touch selector specificity to :hover in some places and use it to help wrap if statements in JS to do one thing for touch and another for no-touch.
Yepnope.js is a third solution that combined with modernizer could help to deliver different js or css files depending on touch or no-touch.
I also found this article, http://blog.0100.tv/2010/05/fixing-the-hover-event-on-the-ipadiphoneipod/, which seems to say that if you attach a jQuery event to the link the iOS behaves differently. Not sure how it works but may be worth checking out.
Updated by Boone Gorges almost 11 years ago
WordPress handles the issue of hover-to-view nav items by adding a body class "mobile" when `wp_is_mobile()`, and then providing specific body.mobile styles. I think this is a good way forward for us, too, in cases like that of BuddyPress Docs. If there are other areas of the Commons interface where you also have to hover to make certain items visible (this does not mean flyout menus, which are handled differently), please list theme here.
Updated by Chris Stein over 10 years ago
- Status changed from New to Resolved
Marking this as resolved for now. There is only one related issue not resolved and that is just to decicde on where a nav item links to.
There may be other issues we haven't found, but for now, the issues we were seeing appear to be resolved one way or another.