IE10 mobile/touch :hover navigation problem

[Ixolite]

Being a happy owner of a new Windows Phone 8 device I stumbled upon a major issue with mobile IE10. Namely, and more precisely, the problem lies with how IE10 handles :hover events with touch input.

All other mobile browser do the same – tap once to activate the :hover event, tap second time to interact with the :hover. This works nice, apart from the little iOS issue of not being able to close a :hover other than clicking some link, however that is not how IE10 works. IE10 treats :hovers like in desktop, mouse based environment – you cannot activate :hover and keep it in that state to interact with it further. That means that any navigational elements that rely on showing you additional options on :hover won’t work with touch operated IE10.

My question is – is there any elegant solution to make the :hover work like in all other mobile, touch operated browsers? Tap to active the :hover event and keep it up until another action is taken by the user?

I’d like to be able to provide navigation for touch IE10 without re-doing whole nav components of the page to address this issue.

[Chris Coyier]

In general, just totally avoid core functionality that is only shown on :hover.

In mobile webkit you are right, if the element has a :hover (but no href) it will stay in it’s :hover state after you tap it once.

That’s a bummer Window Phone 8 browser doesn’t do that… You might have to write some JavaScript that deals with tap events. Like when you tap it applies a class of “hover” and you reveal the menu with that class.

[Chris Coyier]

Also, modenizr has a test for touch events, so you could write specific event handlers for that stuff.

[Ixolite]

Thanks for the quick reply. I’m afraid I will end up JavaScripting this (just like fixing oh so many other issues for IE *sigh*) just like you’re suggesting.

I do like the :hover dropdowns very much though since they are so elegant and compact, simple markup and CSS. I know I shouldn’t use :hover for interactions where touch interfaces are concerned, however that was not an issue if those events were tied to button-like page elements, so users knew there is some action behind them.

Unfortunately this ‘broken’ behaviour of IE10 is not limited to Windows Phone, it is also present on tablet/desktop when using touch interface instead of mouse and keyboard. While it may be correct as far as standards are concerned, it is certainly not what we are used to and not how every other browser works with touch.

[Edit]
I probably should have mentioned that we work with very script-heavy pages so we tend to avoid introducing additional scripts whenever possible. One of the reasons we went with CSS only dropdown.

[greenrobo]

Hey Ixolite,

I see your point. As a mobile user, I figured how to overcome this issue. Usually if you touch or tap the :hoverable element, it will be treated as a click. So I touch+drag away from the element, so that it get focused which is a :hover event and will show the dropdown menu. Hope this help you in navigating on mobile devices although its not a fix ;)

[jonathansampson]

As advocates of standards (and not browsers) we ought to be getting behind proper implementation. Implementing :hover as a toggle, rather than momentary change in state, is fundamentally incorrect. Internet Explorer 10 ought to be praised for *not* following along with broken implementations.

It’s our job, as the developers, to deliver an experience consistent with what is expected. You cannot *hover* on a mobile device, and as such an alternative approach should be taken. Many accessibility experts would argue that revealing important information on :hover is a bad practice entirely. IE may be at fault in many cases, but this isn’t one of them.

[theking2]

I agree with your remark. It’s not good to follow something wrong because other implementers did that. Just look at a long an confusing history of iOS Sarari before they got media queries right.
The problem is that IE10 transports the same behaviour to its desktop and modern implementation. A li:hover will not work in either browser. It is required to dumb it down to IE9.

[mblase75]

Microsoft has a solution here.

It seems adding aria-haspopup="true" to an element will trigger a hover on first tap, and a click on second tap, when using Win8.

[Preface Studios Ltd]

I’m aware that this is an old topic, but has anyone stumbled across this scenario?

Large screen mode – nav menu links are displayed inline. The sub-menu ul is hidden by default, when you hover over a link with a sub-menu, it’s shown. Unless you add aria-haspopup=”true” like below, the submenu never appears on Windows 10/11 using a touch screen device.

<ul class="with-dropdowns">
    <li><a href="#">Home</a></li>
    <li>
        <a href="/about" aria-haspopup="true">About</a>
        <ul>
            <li><a href="/about/#who-we-are">Who we are</a></li>
            <li><a href="/about/#what-we-do">What we do</a></li>
            <li><a href="/about/#why">Why</a></li>
        </ul>
    </li>
    <li><a href="#">Blog</a></li>
    <li><a href="#">Contact</a></li>
</ul>

Fine. What about at small screen size? Here my menu is displayed with each link on a new line (display: block) with the submenu shown underneath by default (with some padding-left so its indenting to indicate hierarchy). Now if I try and touch the parent link on my phone, nothing happens. At least on desktop mode, the menu appears and disappears on touch and if you really want to access the about page you tap the link again. However on a phone it just looks and feels like the menu is broken, as nothing happens when you tap it once, it only works when you tap it twice.

Is there a way of fixing this, other than writing some JS to inject aria-haspopup=”true” at min-width: whateverpx?

[Author]

Posts