The reason to use `hover`, instead of `pointer` like a sibling comment mentioned, is for accessibility purposes:
> For accessibility reasons, even on devices that do support hovering, the UA may give a value of hover: none to this media query, to opt into layouts that work well without hovering.
no i mean that touch devices with a dedicated mouse can be detected as no-hover devices (usually laptops with touch screens)… which is often not desirable
Ah – I err on the other side (keeping things usable for touch input). Two sides to a coin! That is a useful thing to keep in mind when writing this though, good point.
I view this not as "unreliable for detecting touch screen laptops" but reliably detecting touch screens.
I think you're reading the comments backwards, maybe. A laptop that has a mouse and a touch-screen will in some cases NOT be detected as a touch screen. When you say that is "reliably detecting touch screens", I'm not sure if you're following. If that results in delivering your "not as usable for touch screens" UI, that is not "erring on the side of keeping things usable for touch input"
> A laptop that has a mouse and a touch-screen will in some cases NOT be detected as a touch screen
What you are saying here is the opposite of the comment that I'm replying to, and is the opposite of the W3 spec. Are you sure? micromacrofoot correctly said:
> touch devices with a dedicated mouse can be detected as no-hover devices
"no-hover devices" are AKA touch input devices, and will therefore satisfy the query `hover: none`. The spec says as such:
For example, on a touch screen device that can also be controlled by an optional mouse, the `hover` media feature should match `hover: none`, as the primary pointing device (the touch screen) does not allow the user to hover.
However, despite this, the optional mouse does allow users to hover. Authors should therefore be careful not to assume that the ':hover' pseudo class will never match on a device where 'hover:none' is true, but they should design layouts that do not depend on hovering to be fully usable.
I believe what I'm saying is the same thing and you are mis-reading.
> A laptop that has a mouse and a touch-screen will in some cases NOT be detected as a touch screen
You see the "NOT" in all capitals? "NOT be detected as a touch screen".
I said:
> A laptop that has a mouse and a touch-screen will in some cases NOT be detected as a touch screen.
That is the same thing, is it not?
Which is the same thing as you quoted from the spec.
> For example, on a touch screen device that can also be controlled by an optional mouse, the `hover` media feature should match `hover: none`, as the primary pointing device (the touch screen) does not allow the user to hover.
Right, so such devices will be detected as "NOT a touch screen".
I feel like I'm agreeing with the spec and agreeing with micromacrofoot, but you are for some reason still reading it in reverse.
If you detect something with both touch and a mouse as "NOT touch", and then deliver a UI optimized for "NOT touch", this is NOT "erring on the side of keeping things usable for touch input".
But this is now a super boring conversation! If this super boring pedantic explication doesn't get us anywhere else, nothing will, I give up!
Hey, no worries, it's not boring! Specs are just hard to parse. Pedantic is the name of the game with W3 :)
> Right, so such devices will be detected as "NOT a touch screen".
`hover: none` means it's a touch screen.
The idea being that the device shouldn't expect hover inputs. Hence "touch devices with a dedicated mouse can be detected as no-hover devices"
Paraphrased, the bit of the spec I quoted says "even if a touch laptop has a mouse, `hover: none` will still match". Here's a quick fiddle to show: https://jsfiddle.net/b2f69uya/
Ultimately: if you have a touch control as a device's primary input, there's a guarantee that `hover: none` will be satisfied.
> This media query has not yet been implemented and is currently only a proposed spec. I've written this post to raise awareness of it and get general thoughts about it.
Great to be aware of what might come, but.. it's not an option if it's literally just proposed.
