Navigation sidebar scrolling scales with its size

[QuLogic]

Note: I'm using GStreamer docs as an example here, but I believe this problem occurs in all hotdoc users since they all source the navigation scrolling from here. GStreamer docs also have the longest navigation sidebar I could find.

On the GStreamer Application Development Manual, the navigation sidebar is initially short enough to not have a scrollbar on my display.

I then open the Tutorials section, and every tutorial subsection, so that I have a scrollbar on the navigation sidebar. With my mouse hovering over the first element (Installing GStreamer), I scroll one notch and end up between Basic tutorial 2 and 3, which is 4.5 elements down.

If I then open the Plugins section at the bottom (which adds several elements), start at the top, and scroll one notch, I end up between Android Tutorials and Android tutorial 1, which is 28.5 elements down.

That should not happen. Scrolling should always be by the configured number of lines in the browser. Or if that can't be queried from JavaScript, then it should at least be a consistent height.

This test was done Firefox 98. In Chromium, a similar thing occurs, though the size of increase is a bit smaller, going from 2 elements to 12.5 elements.

[MathieuDuponchelle]

Ah, that's an interesting remark, to be honest I just let the default behavior occur, when you say "it should" is there some sort of actual guidelines you're referring to? I'm not a web developer by trade fwiw :)

[QuLogic]

No, not really, just general experience on websites. Having your scroll step size change is completely broken and unintuitive. It makes it very difficult to find anything in the sidebar if it's large because you scroll one click and half the entries are off the screen already. It's more work to move your mouse to an entry, so that's why you use the scroll wheel. But if scrolling moves half the screen, then you have to move the mouse anyway, and that defeats the purpose of scrolling.

In my experience, almost every site that attempts to 'improve' scrolling in JavaScript gets it wrong. It's fine-tuned to whatever system the developer is used to, and never agrees with the browser/system settings. If I were you, I'd just turn off the JavaScript scrolling entirely.

[QuLogic]

I've found a few more sites that probably explain this better, just search for 'scrolljacking' or 'scroll hijacking'; it's mostly a problem of usability, but I think even more strongly, it's poor for accessibility: https://webflow.com/accessibility/checklist/task/avoid-scrolljacking

[ferdnyc]

Was this subsequently addressed? Because, I can't reproduce. (Trying at the GStreamer manual site linked in the first comment, using Google Chrome 118 Linux.) The sidebar scrolls the same distance using my mousewheel, regardless of its current height. When clicking on a sidebar item, if the sidebar is longer than the page, it will jump that item to the top of the page — which can be a bit disconcerting, TBH — but it doesn't affect manual scrolling, at least for me.

The only commit I see regarding scrolling is 07e907e, "disable scroll inertia"... and that was in 2017, so I doubt it's relevant unless GStreamer were still using a really outdated version of hotdoc all the way through 2022.

[MathieuDuponchelle]

oh, yes @ferdnyc , this was addressed with https://github.com/hotdoc/hotdoc_bootstrap_theme/commit/02837d4a27c5ee3025b4d0fc375c23f48b785d44, good call