[Webkit-unassigned] [Bug 158517] New: :hover is sticky on iOS, even on touch-friendly webpages
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Jun 7 23:42:17 PDT 2016
https://bugs.webkit.org/show_bug.cgi?id=158517
Bug ID: 158517
Summary: :hover is sticky on iOS, even on touch-friendly
webpages
Classification: Unclassified
Product: WebKit
Version: Safari 9
Hardware: iOS
OS: iOS 9.3
Status: NEW
Severity: Normal
Priority: P2
Component: Layout and Rendering
Assignee: webkit-unassigned at lists.webkit.org
Reporter: webkit at chrisrebert.com
CC: simon.fraser at apple.com
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/ )
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160608/5a94796d/attachment-0001.html>
More information about the webkit-unassigned
mailing list