158517 2016-06-07 23:42:17 -0700 :hover is sticky on iOS, even on touch-friendly webpages 2022-02-08 23:23:43 -0800 1 1 1 Unclassified WebKit Layout and Rendering Safari 9 iPhone / iPad iOS 10 NEW https://bugs.chromium.org/p/chromium/issues/detail?id=370155 http://jsbin.com/nepisob/edit?html,css,output HasReduction, InRadar P2 Normal --- 159753 1 webkit webkit-unassigned benjamin bfulgham nekr.fabula simon.fraser webkit-bug-importer oldest_to_newest 1200357 0 webkit 2016-06-07 23:42:17 -0700 Steps to reproduce: 1. Open http://output.jsbin.com/nepisob/quiet in iOS 9.3.2 Safari. 2. Tap the cyan "H" button. 3. Ensure your fingers are no longer touching the screen. Expected result: The "H" button should be cyan. Actual result: The "H" button is red, indicating that the :hover pseudo-class is still matching. Sampling of original Bootstrap issues: * https://github.com/twbs/bootstrap/issues/10828 * https://github.com/twbs/bootstrap/issues/12692 * https://github.com/twbs/bootstrap/issues/12832 Related radars: <rdar://problem/15100108> See also: https://bugs.chromium.org/p/chromium/issues/detail?id=370155 Details: Mobile WebKit makes the :hover CSS pseudo-class "sticky" (i.e. continue to match a tapped element until another clickable element gets tapped) in order to accommodate legacy webpages which were only designed with desktop browsers in mind and thus have e.g. menus or tooltips which only appear on hover. Without this stickiness, since touch devices don't typically physically support a real hovering interaction, such widgets would frustrating or impossible for users on touch devices to deal with. Making :hover sticky on such pages is perfectly reasonable. However, modern webpages are usually designed to account for mobile/touch devices, and thus avoid critical hover-only interactions. Many such pages are mobile-first rather than mobile-only, and thus wish to still use :hover (correctly) to slightly enhance the experience of desktop users. The typical example is wanting to change a button's styling on :hover, as an affordance to indicate that it's an interactive button. However, :hover stickiness causes the buttons on these webpages to get stuck in a hovered/selected state after a tap on them has completed, thus confusing the user (and frustrating designers). Currently, the only decent known workaround is to use a JS library such as what-input (https://github.com/ten1seven/what-input , http://ten1seven.github.io/what-input/ ) to track the user's input modality, and make all :hover styles conditional upon a mouse modality. This adds an extra JS dependency, adds a CSS build step (or requires constant discipline when authoring CSS), and may not be robust to the future addition of more input modalities to the Web® Platform™. It is thus a very suboptimal workaround. Therefore, it would be nice if there was some mechanism for webpages to opt out of sticky :hover. (e.g. Perhaps rules similar to those that enable fast-tapping; https://webkit.org/blog/5610/more-responsive-tapping-on-ios/ ) 1203222 1 benjamin 2016-06-16 22:37:22 -0700 I don't think we can easily fix :hover because of legacy content. IMHO, ":active" should match elements under the primary touch point. It also makes more sense with the existing specs. 1203228 2 webkit 2016-06-16 23:14:53 -0700 (In reply to comment #1) > I don't think we can easily fix :hover because of legacy content. I don't understand why you're citing legacy content as a reason, when the suggestion is specifically to *not* change the semantics for legacy content. Only non-legacy content would be affected. > IMHO, ":active" should match elements under the primary touch point. Personally, I would be equally fine with having :hover never apply when using touch input on non-legacy webpages. 1203362 3 benjamin 2016-06-17 11:47:46 -0700 (In reply to comment #2) > (In reply to comment #1) > > I don't think we can easily fix :hover because of legacy content. > > I don't understand why you're citing legacy content as a reason, when the > suggestion > is specifically to *not* change the semantics for legacy content. > Only non-legacy content would be affected. We could certainly have the behavior of :hover change depending on the viewport meta tag or other signals that a page is mobile friendly. I generally try to avoid "modes of operations" like that and prefer to have a consistent behavior. I was not rejecting your idea of getting rid of :hover for mobile. Just giving my opinion on how I would prefer the use case to be handled. 1839032 4 webkit-bug-importer 2022-02-08 23:23:43 -0800 <rdar://problem/88673998>