> On Jan 10, 2016, at 01:46, Isabel Santos <unboun...@gmail.com> wrote: > > Eventually, for newer browsers you could use the css feature query > (@supports), > for a deeper css control, but I'm not sure how.
You can’t use the @supports feature query in this case! It detects whether a browser actually supports a combination of `property:value`, for example: @supports { display: flex; } { E {property:value} } but `hover` is a selector, not a property or value. Interaction media queries [1] is the way to go, eventually (but what would happen on a touch device with a mouse attached, such as the latest Microsoft tablets, or the iPad Pro ?). @media (pointer:fine) { /* for devices with a mouse or trackpad */ button:hover, input[type="button"]:hover { background: yellow; color: red; } } That is supported by the current crop of browsers, except Firefox (check Caniuse.com). For Firefox you can work around (partly) by repeating your above selectors inside an @supports query] @supports (-moz-appearance: none) {} but that would trigger on (handheld, touch) Android devices as well. > On Jan 9, 2016, at 00:49, Tom Livingston <tom...@gmail.com> wrote: > > Is it just a matter of moving the hover styles to > a wider breakpoint? That won't work, except if you also exclude a lot of common window sizes for desktop browsers . Have you checked the CSS-screen size of, e.g. an iPad Pro? (hint: 1024 by 1327px or thereabout); my browser windows are rarely wider that 1100px, esp on the MBA. ——— I rarely, if ever, use :hover effects (and when I do it is usually something very discreet) so I haven’t really thought about this. On top of this, in most cases, when the user presses / taps a button, either the user is taken to another screen, or something happens (JS at work) within the same screen that shifts the focus away from the button, in which case that persistent `:hover` state is removed. It may still persist when the user uses the back button, in which case, you could consider it a bonus :-) — an indication to the user what the last thing he/she did on that page / screen. I do consider it a bit of a bug that it is the `:hover` state that triggers all this, not the `:focus` or `:active` state. Or maybe is yet another unfortunate side effect of web developers doing stupid things such as CSS-only menus, where mobile browsers then need to try to be ”web compatible”. [1] http://www.w3.org/TR/mediaqueries-4/#mf-interaction check this article by Patrick Lauke: https://dev.opera.com/articles/media-features/ Philippe -- Philippe Wittenbergh http://l-c-n.com/ ______________________________________________________________________ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/