I recently had the “pleasure” of having to figure out why a user on one of our websites would get “stuck” trying to scroll near certain elements. Turns out one of the execs uses an iPad Pro in landscape mode exclusively, so it’s often the case that the site is being viewed by someone using a desktop sized viewport but a touchscreen for interaction.
Hover Styles
A funny quirk with Safari is how it decides to handle hover styles. Common wisdom on the web is that touchscreens can’t hover.
With Safari you can. Your first interaction with an element that posseses hover styles makes the hover styles active. This kind of makes sense, actually, since :hover is a pseudo-element. One tap turns the original element into element:hover. To actually use the element, therefore, requires a second interaction.
This was one of the first problems I was asked to troubleshoot; why many of the anchors on the website required a double tap in order to follow.
The fix? Well it’s hard to say. One option is to simply not ship hover styles at all. A better option is to only ship hover styles to devices that we know can use them. This is actually pretty tricky, at least if you want wide browser support. The general wisdom of the last five years or so of web development is that you simply cannot know if your page is being browsed with a mouse pointer or not.
What Are You Really Touching
Another issue that arose was with Google Maps elements on pages that couldn’t be interacted with via touch at all. Inspecting the element and looking at its sibling elements revealed a pseudoelement styled to overlay the map. The reason a user couldn’t open map markers or scroll the map was that they weren’t actually interacting with the map at all. Instead, they were tapping the pseudoelement above it.
We also found ourselves plagued by areas of the website where scrolling would become “stuck”, and tried a number of unsuccessful fixes until noticing something interesting.
In portrait mode evertyhing scrolled as normal. In landscape mode the scrolling would stick. The difference between the two was the navigation - the desktop navigation included “panels” that would appear as secondary menus.
Sure enough, a close look at the DOM revealed that these “panels” weren’t being completely hidden. Instead of touching the main page area when trying to scroll, users were actually touching these invisible panels; styled to cover the viewport and to hide overflow (no scrolling). Here again we found that the issue lied with there being a difference between what a user thought they were interacting with and the element they were actually interacting with.