-
-
Notifications
You must be signed in to change notification settings - Fork 79k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better handling of :hover on mobile by prefixing :hover selectors with .no-touch #13049
Conversation
Personally, I don't like this, but I cannot suggest something else for the time being... The fact that it needs JS and that it bloats the selectors is something that feels too intrusive. |
A reasonable approach might be to audit hover states and make sure they don't overlap with active states like in the Bootply for button groups: http://www.bootply.com/render/116436 I argue that the :hover state could be improved to look much different from .active. Maybe this won't work for every case, but it's a more maintainable approach than trying to prevent :hover states in mobile browsers. |
@ssorallen What's your maintainability concern about this approach? |
@cvrebert The additional Grunt task and the yet-to-be-written JS will require maintenance, and I imagine the JS that checks for touch event support can have bugs. I think mobile browsers got this interaction right, and so this seems like a design problem to me and not something that requires a workaround. Tooltips are an example that I think would suffer from this change. Open the tooltips example on your phone and try tapping each of the buttons under the "Four directions" example. With the change proposed in this pull request, the tooltip would still work but the button would not show its hover state. Tooltips are example of features that mobile browsers had in mind with their mouseover/mouseout implementation; Bootstrap's tooltips wouldn't display at all without the hover emulation. I propose an audit of |
The Grunt task is pretty trivial, FWIW.
@ssorallen Although I personally agree that |
Sticky |
In each of those cases, the |
Just pushed a commit that adds the requisite JavaScript. |
+1 |
Related: h5bp/lazyweb-requests#159 |
Where'd we leave off with this? It seemed like a pretty crazy idea that I never fully understood, so I'm unsure how we should proceed. Perhaps something to re-evalute for v4? |
In our app we got around this by differing the styles from |
CSS4 will have support for So I'd punt this to v4 (or later, depending on when browser support for those is added) |
Closing this out for now just to knock down the list of issues and what not. Still slating it for v4. |
Shameless plug: https://github.com/cvrebert/mq4-hover-hover-shim |
So, this is
one-half of aone possible solution to the problem of how mobile browsers treat:hover
styles (see #12832, among several others).What this does is add a prefix (
.bs-no-touch
) to every CSS selector that involves:hover
and adds some JavaScript to detect whether the user-agent has touch functionality, and if not, then add.bs-no-touch
to the<html>
(or<body>
?) element. (It should be possible to adapt the relevant portion of Modernizr into a tiny JS script for this.) Thus,:hover
styles are only activated on non-touch devices, preventing the afore-referenced UX problems.Issue: Requires JavaScript
:hover
styles.Possible mitigation for (1): Add a
.bs-no-js
<html>
-level class and also autogenerate a.bs-no-js
-prefixed version of every:hover
selector.Downsides of this mitigation:
:hover
-related selectors<html>
-level class and more JS.Another possibility is to require the original HTML to have
body.bs-no-touch
and then instead have the JS remove the class if the device supports touch, but that requirement sounds rather intrusive.Some Relevant Links
CC: @mdo @twbs/team for discussion