HN Reader

As a backend person, sometimes I look at what's being done for front end stuff and pull back in ever so slight horror.

It's an excellent article, and the work within is very well done, but there's a part of me that screams "Why would you introduce this much complexity for what should be a simple scroll?" (overcoming technical hurdles to produce the desired end result aside).

One could ask: what's the UX purpose of the "active anchor" indicator on the side navigation?

One answer I can think of: if a reader is in the middle of a long section, and the heading is off the screen, it can remind them which section they're in relative to the others.

This indicates (to me, anyway) that it's not a function of which heading you've scrolled to; it's a function of which section is on screen. If you use section-screen-area or something similar to highlight the active section, fiddling with the heading positions becomes unnecessary.

If you have a tiny section at the end that can never take up the majority of the screen, then when the user is reading it, the active indicator won't really be useful anyway.

Adding padding below the main page content seems ideal since it also fixes the issue where the tail end of the content is stuck at the bottom of the viewport instead of where you'd prefer it.

Maybe a 90vh margin for mobile and 50vh for everything larger.

Hmm, then again you'd still need TFA's solution for the latter case. The margin only solves it on mobile since a 90vh margin on desktop would look ridiculous.

The article is a neat read! The design of the blog itself is even more interesting. I don't love the right-aligned way it starts, but I love the inline activations of the left popup! So cool

I clicked, thinking that it was perhaps someone who like me was annoyed by Jira's anchors/permalinks which is a <span> with a <button> with a JS event listener on click to load what would normally be an <a href> into the DOM.

But this, this is similar, but different. I can't navigate to anchors with for example the keyboard.

Question for the author: Why not use the HTML <a> element rather than a JS event listener on a non-interactive element?

It's hilarious reading the other comments. I'm on mobile but my first thought was how interesting and novel the site design was and how clearly communicated the problem they were trying to solve

Cool post! It's refreshing to read a blog that doesn't ask me to subscribe with popups etc and gets into technical weeds

In modern browsers, Text fragments let you highlight specific portions of text on a page, be it at the bottom or anywhere. In Chrome, just highlight the text and right click -> Copy link to highlight.

I use it every day instead of anchors to highlight very specific parts of the text, to avoid referring to the whole section with an anchor. Some pages don't even have anchors

Ref: https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...

Another solution I quite like is highlighting the headings of all the sections that are currently on screen.

The animations on the left are exactly what my primitive mind needs to understand better and stay engaged while reading an article. I _love_ it.

So what's going on for someone who doesn't have javascript enabled? No anchor links are available at all.

For my Firefox desktop, even the "beautiful solution" at the end highlights "Middle Section" even if the Conclusion is fully visible, but I'm just not quite at the bottom of the page in terms of scroll.

Surely the answer is to highlight all onscreen anchors. You don't know where my eyes are looking on a page with two headings on it.

Interesting solution. One little tip, I would advise picking a different heading for the section "The final solution". That phrase has a bit of unfortunate historical baggage.

I recently discovered the way Tanstack does this. Basically, if the heading of the section is in the viewport, then the list item is highlighted.

So you could have multiple items highlighted, but it still "works" somewhat intuitively for the end user.

The drawback is that it requires JS via intersection observer. But maybe the CSS standards committee could see value in this kind of thing eventually.

my first instinct would be to let the triggerline move with the scrollposition, i.e. at scrollTop = 0 the triggerline is at 0vh and at scrollTop=max at 100vh... am i missing something?

I dabbled with this kind of issue in my docs and ended up using JavaScript's Intersection Observer [0]. It's not a perfect solution [1], but I think it worked well enough [2]. It just identifies when the element comes on screen and then marks it as active however you please. I do appreciate the depth the article went into though!

[0] https://developer.mozilla.org/en-US/docs/Web/API/Intersectio... [1] https://github.com/keybittech/awayto-v3/blob/main/landing/la... [2] https://awayto.dev/docs/0.3.0/

Hey, another overengineer! :D

My solution was to just highlight the last anchor if the user scrolled to the very bottom. Although this might skip the second last heading if its too close to the bottom.

See here: https://sharezone.net/privacy-policy (most visible on desktop, on mobile you have to open the "Inhaltsverzeichnis" at the bottom)

Another aspect of over engineered anchor links seems to be that at least on Chrome on iOS, back navigation doesn't work properly on this site as a whole.

As of iOS 18.4, macOS 15.4, Details/Summary HTML tags can be styled with CSS.

Which might be an approach for the first few examples.

I am sure there are other cases that would need anchors.

Nice read. Although I much prefer the first solution, the hotfix of adding extra padding to the bottom. UX-wise, not just because it is simpler.

On large screens I prefer to not read texts at the bottom (I always scroll things enough so I am looking at them at the middle or top of the screen). Also, the positioning of the heading relatively to the screen is always the same on every scroll.

Another potential option is to allow for multiple "active" states (everything in view). If the content is long enough, it can kinda work out. As you transition from one section to the next, both headers would be "active". For short content it would highlight too much though.

snake-y example: https://zquestclassic.com/releases/2.55.0/

It's an interesting problem - the approach I've taken in the past is to simply highlight all sections that are on the screen. This is pretty straightforward to do nowadays with intersectionObserver.

Nicely presented article. The way anchor opens up and not letting go the context is good. Overall visual and the ease to access information is appreciated.

Why not open a modal dialog instead?

I find this layout extremely weird and distracting to the point that I couldn't manage to get through the article at all. I would much rather have the fancy stuff as inline callouts, with none of the giant attention-grabbing bright buttons in the middle of the text.

Reading the main content at the bottom right of the window is weird.

Just came to say the blog site itself is awesome, I’d advocate for opening the diagrams automatically on mobile, they’re amazingly slick.

In the final demo, when I click on "Conclusion" in the side nav, it doesn't even bring the content into view.

So over-engineered that I cannot even see them until I enable multiple rounds of JavaScript. And the colour scheme ignores my preferences and hurts my eyes.

I backed right out of whatever that was.

can you make them automatically trigger on scroll if you get close to its section?

Cool I like the exercise in futility :)

Fantastic blog post. I love constrained optimization, it's always pretty to throw a solver at a well-defined problem

FYI on the topic of scroll position, it seems inconsistent between history navigation. For example scroll to the very bottom, click your Internship blog post, and go back - it ends up somewhere towards the end but not quite. (Chrome Mac)

On mobile just clicking the other blog post takes me to the end of that post. (Chrome iOS)

On Android, both the first and last example scroll to "Conclusion" in the exact same way for me, and the heading shows up in the same place within the div they are showing the examples in.

I'm sorry but anything that hijacks the scrollbar in any way is just a no-go. You have to not interfere with scrolling. (Taking some other action on the page during scrolling can be okay, but actually affecting the scrolling itself in any way while you are scrolling should be verboten, in my opinion.)

The new CSS Overflow Specification 5 has scroll-marker that can replace anchor link. From my short test in Chrome 135, they seem to scroll to the right place.

It's a shame that the overengineered anchor links in TFA don't work with the keyboard.

IMO, the most important UX features for anchor links is that you should be able to send them to other people (and save them via bookmarks).

Say that you find yourself needing to check the "Control code table" section of the Wikipedia ASCII article from time to time (for some reason). Being able to bookmark that specific section[1] is much more convenient than having to always start from the top of the page[2] and then scroll down (or click some on some anchor link) to get where you actually want to go.

This thirty-five website doesn't seem to offer that functionality because it doesn't use #anchor-name URLs.

[1]: https://en.wikipedia.org/wiki/ASCII#Control_code_table

[2]: https://en.wikipedia.org/wiki/ASCII

Sounds like a nice solution.

Seems like if you open the "he thinks" image thing at the bottom, and then go back to the "beautiful" result, then it no longer works and the Conclusion heading doesn't get activated. That's how I reproduced it anyway.

Terrible culture that rewards psychopathy. Every CEO is an insane individual that has no remorse for any terrible action they do. This makes perfect sense that their entire corporation would reward breaking rules. It's what they would do afterall.