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...

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).

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?

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.