[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