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.
The "H" button should be cyan.
The "H" button is red,
indicating that the :hover pseudo-class is still matching.
Sampling of original Bootstrap issues:
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/ )
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.
(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.
(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
> 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.