Change the Hover state in Chrome for Touch Devices

[Matt Gaunt]

Hi Everyone,

I realized recently that Chrome for Android (and Chrome OS) will apply hover styles after a user touches an element.

I imagine this behavior is for compatibility with desktop sites which have drop down menus and require hover styles to work.

If a website has a mobile viewport set, I see no reason to give an element hover state, i.e. a developer making a site for mobile devices should assume there is no hover state.

By applying this state after a touch, a developer has to expect any hover styles to stick on mobile. This means adding styles for a pointer hover indicating a button is interactable, can't be separated from an active state when touched on a mobile device.

Looking at IE10 on Windows Phone, they don't set any hover styles for mobile sites.

If anyone has a touch Windows Laptop, I'd be curious to know what behaviors you see on hover, focus and active states on http://jsbin.com/qahilulu/quiet.

I propose that for websites with a viewport <= the device width we reserve hover for devices with some notion of a hovering pointer (i.e. finger or stylus not touching the screen, mouse or graphics tablet which rely on a pointer) and for touches we simply apply the active state.

For Chrome OS touch screen devices like the Pixel, I'd like to see the same behavior, i.e. if viewport is set, assume it's not a legacy site and will work without hover. 

Kind Regards,

Matt

[jakear...@google.com]

On Friday, 2 May 2014 16:22:31 UTC+1, Matt Gaunt wrote:
> I propose that for websites with a viewport <= the device width we reserve hover for devices with some notion of a hovering pointer (i.e. finger or stylus not touching the screen, mouse or graphics tablet which rely on a pointer) and for touches we simply apply the active state.

Strongly agree. I hit this issue only a few days ago and ended up having to set a class of "allowHoverEffects" on the html element, which I removed on touchstart, and put back again on mouseenter.

We used viewport <= the device width to remove the 300ms delay, so it has prescident for meaning "the author is catering for mobile" in regards to touch.

[Rick Byers]

First, I think the principle here is super important.  As we've discussed before, we need to be creating a rational platform for the future of the web where developers aren't constantly fighting against compat hacks.  I didn't realize the extent to which :hover styles could be getting in the way of good site design - I can see why you really don't want those styles lingering.

The first question to ask I think is whether we really need support for :hover with touch at all anymore.  If it were't for compat with old desktop sites, would we want it?  Eg. a site implementing a tap-to-activate menu would surely toggle the menu on 'click', not really want to rely on :hover, right?  The web has come a long way with touch support since we added this.  Our focus should be on developers building mobile optimized sites (which still look good on a desktop) - I hate to make their life harder due to compat for old desktop sites that don't consider touch at all.

If we don't want it long term, maybe we should eliminate it completely without the viewport hack.  I tested IE on a touch laptop and it appears to never set :hover for touch (regardless of the viewport).  IE has a hack for explicitly opting to hover compatibility here (with aria-haspopup): http://msdn.microsoft.com/en-us/library/ie/jj152135(v=vs.85).aspx.  Maybe we should just do the same?  I know they've never been completely happy with this (it's kind of an abuse of ARIA), so if we think it's too hacky we could perhaps standardize something new.

Worst case and we believe we really need to preserve compat here, I'm OK with using the viewport in the heuristic.  It'll be a little odd though (this is a blink decision, and the viewport isn't really known to blink).  And I'm sure we'll still get people complaining that Chrome Android is very different from Mobile Safari and Android browser.

Rick

On Fri, May 2, 2014 at 11:22 AM, Matt Gaunt <matt...@chromium.org> wrote:

Hi Everyone,

I realized recently that Chrome for Android (and Chrome OS) will apply hover styles after a user touches an element.

I imagine this behavior is for compatibility with desktop sites which have drop down menus and require hover styles to work.

If a website has a mobile viewport set, I see no reason to give an element hover state, i.e. a developer making a site for mobile devices should assume there is no hover state.

By applying this state after a touch, a developer has to expect any hover styles to stick on mobile. This means adding styles for a pointer hover indicating a button is interactable, can't be separated from an active state when touched on a mobile device.

Looking at IE10 on Windows Phone, they don't set any hover styles for mobile sites.

Did you check on desktop sites too?  Since IE desktop doesn't even do this for desktop sites, I'd be surprised if IE10 mobile does. 

If anyone has a touch Windows Laptop, I'd be curious to know what behaviors you see on hover, focus and active states on http://jsbin.com/qahilulu/quiet.

I propose that for websites with a viewport <= the device width we reserve hover for devices with some notion of a hovering pointer (i.e. finger or stylus not touching the screen, mouse or graphics tablet which rely on a pointer) and for touches we simply apply the active state.

[Matt Gaunt]

I only tested IE 10 on a mobile and it never sets the hover for mobile sites, on desktop sites it appears to set the hover.

--

Matt Gaunt

Chrome Developer Advocate

[Jake Archibald]

On Fri, May 2, 2014 at 5:14 PM, Rick Byers <rby...@chromium.org> wrote:

Worst case and we believe we really need to preserve compat here,

Removing hover for all touch devices would be great, is there a test we can run?

 

I'm OK with using the viewport in the heuristic.  It'll be a little odd though (this is a blink decision, and the viewport isn't really known to blink).

How was this achieved with the 300ms delay?

 

And I'm sure we'll still get people complaining that Chrome Android is very different from Mobile Safari and Android browser.

I'm not so sure, there isn't a lot of love for how Mobile Safari handles hover https://www.google.co.uk/search?q=hover+ios+safari

[Rick Byers]

On Fri, May 2, 2014 at 12:21 PM, Jake Archibald <jakear...@google.com> wrote:

On Fri, May 2, 2014 at 5:14 PM, Rick Byers <rby...@chromium.org> wrote:

Worst case and we believe we really need to preserve compat here,

Removing hover for all touch devices would be great, is there a test we can run?

 You mean in terms of discovering what sites will break?  I can't think of anything better than trying it and getting feedback in Beta :-)

 

I'm OK with using the viewport in the heuristic.  It'll be a little odd though (this is a blink decision, and the viewport isn't really known to blink).

How was this achieved with the 300ms delay?

The click delay is a chromium feature, not a blink one.  This is all implementation detail though - shouldn't really be a concern when we talk about what's best for the platform (just may affect the resistance from blink engineers). 

And I'm sure we'll still get people complaining that Chrome Android is very different from Mobile Safari and Android browser.

I'm not so sure, there isn't a lot of love for how Mobile Safari handles hover https://www.google.co.uk/search?q=hover+ios+safari

Yeah but we have no way to know who would complain if Safari wasn't doing this (it's only when something that feels natural stops working do you even notice).  I guess the data from IE is probably most useful here.  If IE mobile is really triggering this based on the viewport that's a good sign that there'd be a lot of breakage without it (but then why doesn't IE desktop?).  I can ask the IE team.

[Tom Wiltzius]

+Ojan as we were discussing this yesterday (:hover compat rules as a source of extra invalidations)

[Rick Byers]

I wouldn't expect it to be that common for :hover rules to cause additional perf overhead with touch.  When touch scrolling we shouldn't set :hover at all (unless the finger dwells for >150ms before moving at the start of the scroll).  And then tapping I'd expect :active rules to cause invalidations anyway.  Can you elaborate the ways you've seen :hover cause extra invalidations in touch scenarios?

[Max Heinritz]

I agree with Rick that the #1 priority here should be making mobile-focused web developers' lives easier (because it moves the web forward).  Compatibility with legacy content is important but lower priority.  Given that, I think it makes sense to try to never set :hover on touch devices and see what breaks.

input-dev has a lot on its plate for this quarter.  How involved would this change be?  I expect the technical bit would be straightforward, but reviewing feedback and compatibility issues may take time.

FYI, further discussion of :hover and touch here: https://github.com/google/WebFundamentals/issues/25

[Rick Byers]

On Fri, May 2, 2014 at 4:12 PM, Max Heinritz <m...@chromium.org> wrote:

I agree with Rick that the #1 priority here should be making mobile-focused web developers' lives easier (because it moves the web forward).  Compatibility with legacy content is important but lower priority.  Given that, I think it makes sense to try to never set :hover on touch devices and see what breaks.

By the way, it looks like IE on desktop DOES set :hover, but only as long as it sets :active.  That makes sense and is probably more compatible (I think it's impossible or at least rare for an element to be :active without also being :hover, so not setting :hover at all is probably unnecessary compat risk).

input-dev has a lot on its plate for this quarter.  How involved would this change be?  I expect the technical bit would be straightforward, but reviewing feedback and compatibility issues may take time.

Assuming we're happy with setting and clearing :hover along with :active then I think both the implementation and review would be trivial (otherwise it's a bit more involved).  The hardest part will be deciding how much negative feedback constitutes enough to revert it, but we can always try - maybe we'll get no negative feedback at all!

[Tom Wiltzius]

Polymer UI elements (e.g. the demo in app-widgets) have components that work on both desktop and mobile, and as such they have :hover and :active pseudo-classes that are different.

Are you saying that on a slow tap we won't ever fire :hover, only :active, or at least fire them both in the same frame? If so, then you're right this isn't a concern for over-invalidation. In my conversation with Ojan yesterday we weren't clear on the exact behavior so perhaps we misunderstood what it was doing.

[Rick Byers]

On Fri, May 2, 2014 at 4:43 PM, Tom Wiltzius <wilt...@chromium.org> wrote:

Polymer UI elements (e.g. the demo in app-widgets) have components that work on both desktop and mobile, and as such they have :hover and :active pseudo-classes that are different.

Are you saying that on a slow tap we won't ever fire :hover, only :active, or at least fire them both in the same frame? If so, then you're right this isn't a concern for over-invalidation. In my conversation with Ojan yesterday we weren't clear on the exact behavior so perhaps we misunderstood what it was doing.

Right, they'll both be set at the exact same time (all happens as part of the same hit testing codepath down in Docment::updateHoverActiveState in response to a GestureShowPress event).  

[Tom Wiltzius]

And so the salient bit we should evangelize is that :hover selectors when there isn't an :active selector present might still fire on mobile, though, with all the visual/performance implications?

[Alexandre Elias]

Some sites hide essential functionality inside hover menus are are completely unusable without them: that's a fundamental issue that's not going to be outweighed by any other concerns about consistency or developer friendliness or whatnot.  So I would push back against anything that regresses behavior on sites that don't have a meta viewport or @viewport tag, when Chrome is running on a device that typically only has a touchscreen (i.e. Android).  I don't mind if we change the behavior for mobile sites or touch-enabled laptops, though.

[Nat Duca]

OS-specfic behavior is very anti-web-platform. Lets avoid that.

Given that, I hear two options here:

1) do the work to figure out how to make this work all the time, homogenously across all platforms

2) make behavior different based on meta viewport proprerties.

Is that about right, just high level? It seems like the more and more I look around at the state of the mobile web, I find that there're tons of problems that become easier if you can say "I solemnly swear I'm part of the well-intentioned mobile web."

I also hear that maybe we're a bit full-up on tasks to assign someone to do the work this quarter. Should we put this on our Q3 planning doc and revisit when that time comes?

[Max Heinritz]

Discussed with Nat and Rick.  We decided to start with disabling :hover on touch on sites with a viewport.  Filed http://crbug.com/370155

[Matt Gaunt]

François Remy posted this on Twitter, an explanation of hover on IE11: http://msdn.microsoft.com/en-us/library/ie/dn265029(v=vs.85).aspx

Essentially, hover is shown on a long press or when aria haspopup. 

The advice from the page:

"Hover-based user experiences are fundamentally not optimized for touch, and there's no standardized way for web browsers to respond to touch input in such scenarios. Additionally, hover menus are generally poor for accessibility and not ideal for mouse efficiency either.

The best practice is to not use hover to hide content that a user can interact with. Instead, consider using the click event to toggle the visibility."