Hacker News Reader

Comment by myfonj | Hacker News Reader

Seems clever and all, but `body:hover` will most probably completely miss all "keyboard-only" users and users with user agents (assistive technologies) that do not use pointer devices.

Yes, these are marginal groups perhaps, but it is always super bad sign seeing them excluded in any way.

I am not sure (I doubt) there is a 100 % reliable way to detect that "real user is reading this article (and issue HTTP request)" from baseline CSS in every single user agent out there (some of them might not support CSS at all, after all, or have loading of any kind of decorative images from CSS disabled).

There are modern selectors that could help, like :root:focus-within (requiring that user would actually focus something interactive there, what again is not guaranteed for al agents to trigger such selector), and/or bleeding edge scroll-linked animations (`@scroll-timeline`). But again, braille readers will probably remain left out.

View on HN

Marginal? Surely this affects 50%+ of user-agents, i.e. phones and tablets which don't support :hover? (without a mouse being plugged in)

I think most mobile browsers emit "hover" state whenever you tap / drag / swipe over something in the page. "active" state is even more reliable IMO. But yes, you are right that it is problematic. Quoting MDN page about ":hover" [1]:

> Note: The :hover pseudo-class is problematic on touchscreens. Depending on the browser, the :hover pseudo-class might never match, match only for a moment after touching an element, or continue to match even after the user has stopped touching and until the user touches another element. Web developers should make sure that content is accessible on devices with limited or non-existent hovering capabilities.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/:hover

They had to, and had to make that decision when mobile browsers were first developed, because so many sites had navigation flyouts that relied on :hover. So they had to have something trigger that pseudoselector.

I really wish modern touchscreens spent the extra few cents to support hover. Samsung devices from the ~2012 era all supported detection of fingers hovering near the screen. I suspect it’s terrible patent laws holding back this technology, like most technologies that aren’t headline features.

That's interesting. Did they pass the :hover event down to the browser?

I have to have two interfaces for my web apps, because sometimes I want to hide some text of marginal value behind a :hover, but only a mouse can see it unless I break it out somehow for touch.

I’d be surprised if it was related to patent law; hover detection is fundamentally straightforward with capacitive touchscreens and it’s just a matter of calibrating the capacitance curve, and deciding whether to expose a hover state or not.

No, the reason is just because it’s too fiddly and too unreliable (to use, I mean, more than the touchscreen itself being unreliable, though the more sensitive you tune it the more that will become a problem as well).

Apple had their 3D Touch and they dropped it because (from what I hear, I never used it) it largely confused people due to non-obviousness/non-familiarity, required more care to use accurately than people liked (or, in some cases, were able to provide), and could become unreliable.

I’ve used a variety of “normal” capacitive touchscreens that could be activated anywhere from a few millimetres from the surface to requiring a firm/large-surface-area touch. It’s all about how they’re calibrated, and how much they’ve deteriorated (public space ones seem to often go very bad astonishingly quickly).

Most recently, in Indian airports the checkin machines that you can choose to use say that they’re touchless, that you can just put your finger near and it will work and isn’t that all lovely and COVID-19-aware of them, but on three separate machines I’ve tried it very carefully and couldn’t get it to activate before touching the screen.

Keyboard only users? All 10 of them? ;)

Well with me, it's probably 11.

Joking aside, I love to read websites with keybaords, esp. if I'm reading blogs. So, it's possible that sometimes my pointer is out there somewhere to prevent distraction.

I think there might be more than ten [1] blind folks using computers out there, most of them not using pointing devices at all or not in a way that would produce "hover".

[1] was it base ten, right?

Think about screen readers.

I'm a keyboard user when on my computer, qutebrowser but I think your sentiments are correct, the numbers of keyboard only users are probably much much smaller than the number of people using Adblock. So OPs method is likely to produce a more accurate analytics than a JavaScript only design.

OP just thought of a creative, effective and probably faster more code efficient way to do analytics. I love it, thanks OP for sharing it

https://www.youtube.com/watch?v=lKie-vgUGdI

As written, it depends on where your pointer is, if your device has one. If it’s within the centre 760px (the content column plus 20px padding on each side), it’ll activate, but if it’s not, it won’t. This means that some keyboard users will be caught, and some mouse users (especially those with larger viewports) won’t.

Reply on news.ycombinator.com