Better handling of :hover on mobile by prefixing :hover selectors with .no-touch#13049
Better handling of :hover on mobile by prefixing :hover selectors with .no-touch#13049cvrebert wants to merge 4 commits into
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. |
cvrebert
changed the title
|
+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 |
7 participants
So, this is
one-half of aone possible solution to the problem of how mobile browsers treat:hoverstyles (see #12832, among several others).What this does is add a prefix (
.bs-no-touch) to every CSS selector that involves:hoverand adds some JavaScript to detect whether the user-agent has touch functionality, and if not, then add.bs-no-touchto the<html>(or<body>?) element. (It should be possible to adapt the relevant portion of Modernizr into a tiny JS script for this.) Thus,:hoverstyles are only activated on non-touch devices, preventing the afore-referenced UX problems.Issue: Requires JavaScript
:hoverstyles.Possible mitigation for (1): Add a
.bs-no-js<html>-level class and also autogenerate a.bs-no-js-prefixed version of every:hoverselector.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-touchand 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