A Polyfill for @media (hover)

[cvrebert]

From the CSS Media Queries Level 4 draft.

I think a server-side CSS postprocessor that converts

@media (hover) {
  .some-selector {
    prop: value;
  }
}

into

.no-touch .some-selector {
  prop: value;
}

(with the name of the .no-touch class being customizable) would be a good option.

[roblarsen]

I'm typing this comment on a touchscreen laptop.

[cvrebert]

Done: https://github.com/cvrebert/mq4-hover-hover-shim
Enjoy.

[stucox]

Really not gonna do the job, is it...

My PC would currently match the 'hover' rule in this script, even though there isn't a mouse or any other hover-capable device connected. There are probably loads of other false-positives / false negatives.

The main use cases for the original spec were to enable functionality which requires hover capability for those with such a capability. Subsequent discussions have put emphasis on this MQ depending on manufacturers' insight into how they expect their devices to be used… the complexity of this may explain why we haven't seen much uptake.

---

That said, in a few tests I had reasonable success detecting a "hover user" by looking for 2 consecutive mousemove events without an intervening mousedown (I forget exactly what pattern I settled on — I can try and dig out the code if anyone's interested).

Obvious downside being that you never know if they're not a hover user: just that they haven't used hover yet. Not sure how you'd convey an undefined state in an MQ... maybe don't match none, hover OR on-demand?

[stuartpb]

Yeah, in general - as I've written before - the solution isn't pivoting your hover use based on the device's capability for hover, it's to never design an interface around hovering. Even on devices that do support "proper hovering", I, as a user, don't want to deal with them.

[stuartpb]

Hover is incidental.

A hover represents a tentative, potential interaction, and not an actual, intentional user action. A hover is a slight glimmer above the surface of interaction, across paradigms - it's moving your cursor to show that you're looking at the link, not touching it. Anything that uses hover should only be adding a thin veneer of flair. This veneer should be designed with the state of mind that the hover might not occur, out of device support, laziness, privacy, coincidence, or otherwise.

Designing around the presence of potential hover is bad design. Designing based on assumptions around the only two pointer interaction paradigms you currently know of is incredibly shortsighted, especially at this point in time where there is so much consumer innovation in the space.

It's short-sighted designs like this that necessitated the awful "drag a virtual mouse around" hack on Windows tablets circa Windows 7 - because lame UX designers couldn't imagine a world without mice. Designing based on thinking that "some devices support hover and some don't" is to have the same kind of short-sightedness, not being able to imagine a world without cursors or fingers.

[cvrebert]

@stuartpb

Anything that uses hover should only be adding a thin veneer of flair. This veneer should be designed with the state of mind that the hover might not occur, out of device support, laziness, privacy, coincidence, or otherwise.

I agree. My main use-case is (when possible) making buttons a darker color on :hover (to help indicate that they're buttons) without them getting stuck in the hovered state because :hover is sticky on mobile. If you try to use the polyfill's powers for more sophisticated inadvisable stuff, that's at your own peril.

[stuartpb]

@cvrebert Ech, I see. It seems like this would be better handled by a polyfill that removes that behavior from UAs like FastClick, though.

[stuartpb]

And/or a combination of meta-tags that signals not to do sticky hover (the way setting a viewport or disabling zoom or whatever disables tap-to-zoom and removes the need to polyfill with FastClick).

[cvrebert]

And/or a combination of meta-tags that signals not to do sticky hover

Yeah, Chrome has an open bug for that. But it hasn't been implemented yet, I haven't seem any movement from the other browser vendors on it, and it will never solve Android pre-v5, which an annoying amount of people care about.

[cvrebert]

@stucox

My PC would currently match the 'hover' rule in this script, even though there isn't a mouse or any other hover-capable device connected.

You think it would, or you've actually tried it (test page here) and it does? What kind of device and browser? I'd love to hear details.

There are probably loads of other false-positives / false negatives.

Well, that's the beauty of open source, isn't it? The community tries things out in a kajillion environments, finds where they break, and then they get fixed.

[stucox]

Given the use case, I think this is quite tidy.

Potentially flaky detect, sure, but hidden away so CSS authors can just use an MQ everywhere they need it and it's not the end of the world when edge cases slip through the net.

And no need to deal with the notoriously inconsistent event firing sequences of input devices.

[stucox]

You think it would, or you've actually tried it (test page here) and it does? What kind of device and browser? I'd love to hear details.

Fair call, I was assuming that most desktop browsers don't support it natively yet and wouldnt be blacklisted by your "touch" checks, so would report hover capable — but I'll test it fo' real tomorrow.

[stuartpb]

On the flip side, It thinks my touch-enabled Chromebook does not support hovering:

We think your browser DOES NOT support non-emulated hovering.

e.g. You are using a touch-based mobile device.

[cvrebert]

@stuartpb As mentioned on https://github.com/cvrebert/mq4-hover-hover-shim#browser-side-feature-detector

If the browser does not natively support the hover media feature, but does support touch via some pointing input device, then we define this touch-based pointer to be the "primary pointer". Hence, if said browser has multiple pointing input devices, one supporting touch and another supporting true hovering (e.g. the computer has both a mouse and a touchscreen), this function will return false, since the user could use the touch input device at any time and since :hover should only be used for progressive enhancement anyway.

It's the best we can do in browsers that lack the Working Draft's "primary pointer" concept.