> 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/
