5 ms·

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

by myfonj 3y ago

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.

deleted 3y ago
[deleted]
demondemidi 3y ago
Keyboard only users? All 10 of them? ;)
- myfonj 3y ago
  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?
- bayindirh 3y ago
  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.
- zichy 3y ago
  Think about screen readers.
- vivekd 3y ago
  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
- paulddraper 3y ago
  https://www.youtube.com/watch?v=lKie-vgUGdI https://www.youtube.com/watch?v=lKie-vgUGdI
qingcharles 3y ago
Marginal? Surely this affects 50%+ of user-agents, i.e. phones and tablets which don't support :hover? (without a mouse being plugged in)
- myfonj 3y ago
  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 https://developer.mozilla.org/en-US/docs/Web/CSS/:hover
  - isleyaardvark 3y ago
    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.
- callalex 3y ago
  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.
  - qingcharles 3y ago
    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.
chrismorgan 3y ago
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.

by myfonj 3y ago

deleted 3y ago

[deleted]

demondemidi 3y ago

Keyboard only users? All 10 of them? ;)

myfonj 3y ago
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?
bayindirh 3y ago
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.
zichy 3y ago
Think about screen readers.
vivekd 3y ago
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
paulddraper 3y ago
https://www.youtube.com/watch?v=lKie-vgUGdI https://www.youtube.com/watch?v=lKie-vgUGdI

qingcharles 3y ago

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

myfonj 3y ago
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 https://developer.mozilla.org/en-US/docs/Web/CSS/:hover
- isleyaardvark 3y ago
  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.
callalex 3y ago
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.
- qingcharles 3y ago
  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.

chrismorgan 3y ago

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.