I use a browser extension [1] which provides vim-like bindings for Chrome, and sites that scrolljack severely mess up the scroll up/down functionality.
It's hard to tell there's scrolljacking just by using your mousewheel, but if you try running `window.scrollBy(0, 500);` in your developer console, you'll see the easing being applied. Try the same code on a site without scrolljacking (like the HN front page) and you'll see it jumps directly to the destination.
You'd think one of the largest advocates for web standards and accessibility would know better!
Edit: Another person pointed out that it's caused by the scroll-behavior: smooth; style. I'm guessing they won't change the MDN website and the extensions will need to ignore/disable the style through CSSOM.
The property docs say "User agents are allowed to ignore this property.", so I guess that makes sense.
Dev tools to fix sites during one off visits and Stylus for regular visits. Stylus is an absolutely essential add-on for me in recent years.
It's useless trying to convince the world to have sane, readable text size and contrast on desktop. Firefox reader view doesn't work well with interactive pages.
Pardon my ignorance on this. I am not sure if the easing of scroll motion is scrolljacking.
> Scrolljacking basically means we replace native scrolling (what you’re used to) with targeted scrolling: when the user initiates a scroll, either with their mouse or keyboard, scrolljacking takes them to an exact vertical point on the screen (for example, the top of the next content container)
They aren't targeting your scrolling to specific areas on the page, just adding an ease in/out. It happens natively on iOS actually.
Edit: I do agree that it might hinder accessibility, just dont think the term applies as it does in other cases here.
If you got that from Google's snippet, it's a bad snippet. Scrolljacking is short for "scroll hijacking" and can mean screwing with the browser's default (which we can assume to be user's preferred, or at least expected) scrolling behavior in any number of ways.
MDN isn't scrolljacking, they just set “scroll-behavior: smooth;” [1]. It's a native CSS property and integrates with native scrolling, which is why mouse wheels, touchpads, touchscreens, etc are working fine. I would open a bug report with the extension, it needs to specify the scrolling mode it wants, rather than defaulting to whatever the website chose.
Actually this is quite promising, given how the pages give some alternate recipes and rationale for the design choices.
I have just learned how to fix a broken sticky footer in a way that I had not thought of (100vh on body min-height), I had originally done it differently before I trimmed out what I thought was redundant CSS.
Mozilla need to do more work though for it to be a truly useful resource. Rachel Andrew's 'grid by example' is more likely to solve the layout problems I encounter. Not sure why Mozilla couldn't launch this 'cookbook' without making this new resource at least as expansive as what Rachel Andrew can do.
26 comments
[ 1.7 ms ] story [ 75.4 ms ] threadI use a browser extension [1] which provides vim-like bindings for Chrome, and sites that scrolljack severely mess up the scroll up/down functionality.
It's hard to tell there's scrolljacking just by using your mousewheel, but if you try running `window.scrollBy(0, 500);` in your developer console, you'll see the easing being applied. Try the same code on a site without scrolljacking (like the HN front page) and you'll see it jumps directly to the destination.
You'd think one of the largest advocates for web standards and accessibility would know better!
[1]: https://github.com/brookhong/Surfingkeys
Checking archive.org, it looks like the scrolljacking was just added on October 12.
Try add that style to this (HN) comments page. Same problem.
Seems like the vim addons aren't dealing with browsers' implementations of that style. Whoops.
For the addon I use (Vimium-FF), it appears to have been already reported and fixed: https://github.com/philc/vimium/pull/3111 but not yet published to AMO.
I opened an issue with SurfingKeys: https://github.com/brookhong/Surfingkeys/issues/837
I posted a thread on the MDN discord: https://discourse.mozilla.org/t/scrolling-behavior-on-mdn/32...
Edit: Another person pointed out that it's caused by the scroll-behavior: smooth; style. I'm guessing they won't change the MDN website and the extensions will need to ignore/disable the style through CSSOM.
The property docs say "User agents are allowed to ignore this property.", so I guess that makes sense.
It's useless trying to convince the world to have sane, readable text size and contrast on desktop. Firefox reader view doesn't work well with interactive pages.
> Scrolljacking basically means we replace native scrolling (what you’re used to) with targeted scrolling: when the user initiates a scroll, either with their mouse or keyboard, scrolljacking takes them to an exact vertical point on the screen (for example, the top of the next content container)
They aren't targeting your scrolling to specific areas on the page, just adding an ease in/out. It happens natively on iOS actually.
Edit: I do agree that it might hinder accessibility, just dont think the term applies as it does in other cases here.
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-beha...
I have just learned how to fix a broken sticky footer in a way that I had not thought of (100vh on body min-height), I had originally done it differently before I trimmed out what I thought was redundant CSS.
Mozilla need to do more work though for it to be a truly useful resource. Rachel Andrew's 'grid by example' is more likely to solve the layout problems I encounter. Not sure why Mozilla couldn't launch this 'cookbook' without making this new resource at least as expansive as what Rachel Andrew can do.
https://gridbyexample.com/
Edit: Just tried the first one in JSFiddle and it looks kind of bad. https://jsfiddle.net/n2fole00/ewurbgdn/