4 ms·

It’s possible I’m lacking imagination after ~20 years of web dev experience, but I can’t think of a way to systematically prevent this. I can hardly even think

It’s possible I’m lacking imagination after ~20 years of web dev experience, but I can’t think of a way to systematically prevent this. I can hardly even think of a heuristic to detect it which wouldn’t be either overly broad or overly specific. A spec which privileged more of a page’s “chrome” as part of the browser UX would probably make that more realistic, at the expense of being a very high value attack surface. This is almost certainly better addressed by discouraging and shaming than by trying to fix it at the browser level. I agree with the clarity and brevity of the article (even if I can’t muster such brevity to save my life). And it’s very rare that this kind of UX is any more onerous to me than closing the tab/leaving the site.

ushakov 4y ago
overflow: hidden
- eyelidlessness 4y ago
  That’s effectively the same behavior as a footer below an infinite scroll. It’s just more obviously stubborn about it.
wtallis 4y ago
Aside from a handful of web applications (like Google Maps), I struggle to think of a good reason for sites to be able to observe or hijack scrolling behavior. That capability is abused far more often that it actually leads to improved usability, and I don't think the web in general would suffer from sites being denied that power by default.
- ushakov 4y ago
  observing is great for marketing pages overriding scrolling behaviour or virtual scrolling is a complete no-go eg. this one: https://www.fortnitelookbook.com/en https://www.fortnitelookbook.com/en
  - wtallis 4y ago
    Every scroll-related behavior on that page is entirely gratuitous, and it made my laptop's fan spin up audibly. I'm not sold.
- eyelidlessness 4y ago
  I understand your perspective but for you and anyone else reading, here’s a more familiar analysis. Maps apps don’t make much use of scroll APIs at all, they tend to use pointer events (and/or their older mouse equivalents). When they do it’s almost always auto-panning to some item in a more traditional results list, and always a horrible experience. Apart from infinite scroll, the most common uses of scroll-related APIs are: - deferring load/execution of resources until they’re pertinent; this is almost always a better UX, unless it’s done very poorly (side eye at many news sites) - removing offscreen elements from long lists to minimize their performance impact; again almost always a UX benefit unless done poorly, though easier to screw up - restoring scroll position between interactions; generally neutral, about the same level of quality as built in behavior, but better than not doing it when there’s client-side navigation (and I know this is another JS curmudgeon complaint, but it’s almost everywhere and mostly unnoticed) - scroll-snap, which has eliminated the need for JS for whole classes of presentation (and probably the first unambiguously good thing MS purposefully introduced to web standards) - offsetting jump in-page anchor/jump links to place content in view where they’d otherwise be obstructed; significantly benefits UX, unfortunately not (yet?) as widely adopted as I’d prefer - “scrollytelling”, which can be really annoying but also can be incredibly useful if done well; notably a CSS standard is finally getting real world traction and will make the usage much more user controllable and much less awful for users who don’t control it - shady tracking stuff which is mostly invisible to the user; entirely awful but categorically a whole separate UX topic - weird event handlers to control things like video volume; I hate these with a burning passion Overall, IMO, the value is kind of a wash. But the positives generally amplify positives for a lot of other UX problems and newer standards have made them basically mostly harmless.
  - wtallis 4y ago
    For almost all the uses you've listed, I can readily think of examples where I've seen it done badly. Thinking of good examples is considerably harder. Can you provide some? In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading. And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior. Removing elements after you scroll past them sounds like the kind of optimization only necessary on infinite scroll pages, unless the page in question has a multitude of auto-playing videos. Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help. Scroll-snap: The examples on MDN don't even behave properly. Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve. I'm not sure scroll hijacking is completely bad, but it's overwhelmingly more bad than good. Breaking fundamental interaction mechanisms should only be done where it's absolutely necessary, or in a context where all the normal expectations for interaction can be abandoned. These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers.
wruza 4y ago
Yeah, discouraging and shaming always works. Many of examples out there.

ushakov 4y ago

overflow: hidden

eyelidlessness 4y ago
That’s effectively the same behavior as a footer below an infinite scroll. It’s just more obviously stubborn about it.

wtallis 4y ago

Aside from a handful of web applications (like Google Maps), I struggle to think of a good reason for sites to be able to observe or hijack scrolling behavior. That capability is abused far more often that it actually leads to improved usability, and I don't think the web in general would suffer from sites being denied that power by default.

ushakov 4y ago
observing is great for marketing pages overriding scrolling behaviour or virtual scrolling is a complete no-go eg. this one: https://www.fortnitelookbook.com/en https://www.fortnitelookbook.com/en
- wtallis 4y ago
  Every scroll-related behavior on that page is entirely gratuitous, and it made my laptop's fan spin up audibly. I'm not sold.
eyelidlessness 4y ago
I understand your perspective but for you and anyone else reading, here’s a more familiar analysis. Maps apps don’t make much use of scroll APIs at all, they tend to use pointer events (and/or their older mouse equivalents). When they do it’s almost always auto-panning to some item in a more traditional results list, and always a horrible experience. Apart from infinite scroll, the most common uses of scroll-related APIs are: - deferring load/execution of resources until they’re pertinent; this is almost always a better UX, unless it’s done very poorly (side eye at many news sites) - removing offscreen elements from long lists to minimize their performance impact; again almost always a UX benefit unless done poorly, though easier to screw up - restoring scroll position between interactions; generally neutral, about the same level of quality as built in behavior, but better than not doing it when there’s client-side navigation (and I know this is another JS curmudgeon complaint, but it’s almost everywhere and mostly unnoticed) - scroll-snap, which has eliminated the need for JS for whole classes of presentation (and probably the first unambiguously good thing MS purposefully introduced to web standards) - offsetting jump in-page anchor/jump links to place content in view where they’d otherwise be obstructed; significantly benefits UX, unfortunately not (yet?) as widely adopted as I’d prefer - “scrollytelling”, which can be really annoying but also can be incredibly useful if done well; notably a CSS standard is finally getting real world traction and will make the usage much more user controllable and much less awful for users who don’t control it - shady tracking stuff which is mostly invisible to the user; entirely awful but categorically a whole separate UX topic - weird event handlers to control things like video volume; I hate these with a burning passion Overall, IMO, the value is kind of a wash. But the positives generally amplify positives for a lot of other UX problems and newer standards have made them basically mostly harmless.
- wtallis 4y ago
  For almost all the uses you've listed, I can readily think of examples where I've seen it done badly. Thinking of good examples is considerably harder. Can you provide some? In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading. And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior. Removing elements after you scroll past them sounds like the kind of optimization only necessary on infinite scroll pages, unless the page in question has a multitude of auto-playing videos. Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help. Scroll-snap: The examples on MDN don't even behave properly. Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve. I'm not sure scroll hijacking is completely bad, but it's overwhelmingly more bad than good. Breaking fundamental interaction mechanisms should only be done where it's absolutely necessary, or in a context where all the normal expectations for interaction can be abandoned. These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers.

wruza 4y ago

Yeah, discouraging and shaming always works. Many of examples out there.