Quiet navigation links

6 September 2025

By August 2023, instead of a scrollable collection of navigation links at the bottom of each web page, or web article, which is the same in my case, I had a small button in the left margin, which could invoke the navlinks at any time. The problem with that however was, that when the navlinks were already visible, like under a very short article, or under a long one scrolled all the way down, the block of links nervously jumped up and down, also changing the scroll position, when hovering over the button or the links. That was stupid, ugly and irritating.

Yesterday, I developed a solution using Javascript. The communication on my site is largely one way, author to reader. There is hardly any interaction. For that, using static HTML only is sufficient. So I never used Javascript before, with the sole exception of reloading the page after changing the colour preference. That’s probably also something that could have been done in a much better way. Yes, of course, also with Javascript, I now realise.

The idea of the navigation button improvement is simple: disable the button when it isn’t needed. So in Javascript I detect if the navigation links are visible in the viewport, using code suggestions found in a Javascript tutorial. If visible, I make the button invisible, so also unclickable. In addition, I change the class of the block of navigation links, from rh-navifooter-content to rh-navifooter-content-nohover. That class shares all the characteristics of rh-navifooter-content, except that it doesn’t invoke the menu when hovered, i.e. it doesn’t set position:fixed to the bottom of the viewport.

All of this is handled in my site-wide central CSS file textfont.css .

To find the block of navigation links in Javascript at all times, even after temporarily changing its class, I gave it an extra id=rh-navifooter-content everywhere in the HTML, in 1872 files. Not by hand of course, but with a shell script to apply sed to multiple paths and files. I could have added that id temporarily in Javascript, but somehow I preferred to hard code it in HTML.

I added event listeners, so the Javascript code is executed on initital page load, and when the user scrolls the page, and also on a resize event. Such an event, tests reveal, occurs when the window is made smaller or larger, but also when zooming the text in or out, which on a laptop or desktop computer can be done using ctrl-mousewheel. That makes sense: although the number of physical pixels in the window stays the same, the number of logical pixels changes, because fonts are displayed larger or smaller. So it is indeed a logical resize of the window.

Obviously, all such events can change the visibility of the navigation links, so the necessity of having a button to invoke them needs to be reconsidered. After a suggestion by Grok, checks are now performed no more than 10 times a second, regardless of how fast events happen to occur. A faster response is unnecessary.