I'm just going to post the salient points from support ticket #018688536:

Original ticket:

While it is possible to create HTML anchors in the text boxes in Bulletin Boards and Topics in the LMS, attempts to link to those anchors "fail" because the location hash is used to navigate to, say, #topicdetail.

The expected behavior is that the page will scroll to bring the anchored text into view (as happens with this URL: https://en.wikipedia.org/wiki/Hypertext#Implementations -- the Implementations section should be at the top of the window).

Because the hash is already set, the browser does not automatically scroll to the anchor as naively desired, which defeats the purpose of creating the anchor in the first place: https://groton.myschoolapp.com/app/faculty#topicdetail/1252895/94137853/94137854/2447439/0/1#anchor_3 -- note that anchor_3 is not at the top of the window.

This requires some front-end programming work (i.e. check the location href for an anchor and test to see if the anchor is present in the page after content loads, and then scroll the page to bring the anchor into view), as is done here: https://docs.google.com/document/d/12tCXz6WgfEs0mEZIZYE0VU2nO_G3_IEP1rcVrDladTM/edit#heading=h.4jcada70etjg -- anchor_3 is in view.

For example, consider this (quasi) working example: https://groton.myschoolapp.com/app/faculty#topicdetail/1252895/94137853/94137854/2447439/0/0#anchor_3 where I have added an embed block with a time delay and a little regex to create the desired behavior:

window.setTimeout(() => {
const anchor = window.location.hash.match(/#.*(#.*)/);
if (anchor && anchor[1]) {
document.querySelector(anchor[1]).scrollIntoView();
}
}, 1000);

Response from Bb Support:

[...looking into it internally...]

In the meantime, please check out the following Knowledge Base article, and let me know whether these steps are helpful? If there is another process that has been utilized because these steps do not accomplish what is needed, please provide me with the additional details so that I can better assist you.

https://kb.blackbaud.com/knowledgebase/articles/Article/98071

My response:

Those directions seem like they should work. But...

- I only get the drop down to select an anchor when editing a link within the _same_ content item that the anchor itself resides in. A pretty narrow use case.
- When I create the link this way (bottom of https://groton.myschoolapp.com/app/faculty#topicdetail/1252895/94137853/94137854/2447439/0/0 ), it creates a URL that breaks the UI -- it takes me to a "blank page", because it redirects from #topicdetail, which was used to determine what to show me.

So... no way to use the GUI to create a link to an anchor from even another content item on the same topic page, let alone from another topic page, or from an external website (or URL). **And** the link that the GUI creates is broken.

This cause is straight-forward: using the hash to choose which UI template to display (e.g. #topicdetail/1252895/94137853/94137854/2447439/0/0) means that there is no second hash (there can be only one -- like the Highlander) available to link to an anchor. This is how the web and URLs work.

So... turns out it's _more_ broken than I thought.

I think the temporary band-aid fix is exactly what I proposed originally (the JavaScript snippet that detects an attempted second hash). The long term fix is to redesign the UI to not use the hash when what it really needs is a path.

Bb Support redirects me to this feature request.

Final thoughts:

The question of whether websites _should_ use the URL fragment/hash as a part of their front-end UI is old. And the general consensus is that it's a bad idea. But, clearly, that ship has sailed already in this LMS.

https://www.w3.org/blog/2011/05/hash-uris/

In fact, check this use of the hash fragment in Chrome, without even having to rely on the underlying HTML:

https://www.w3.org/blog/2011/05/hash-uris/#:~:text=no%20longer%20true.-,Good%20Practice,-Having%20looked%20at

I think the fact that I can only reference an anchor from within the _same_ text block is just... is just... is just... embarrassing. That I can't reference it from outside the page at all is surprising, and, I think, entirely discontinuous with the idea of providing the anchor tags in the UI to begin with. The use case for the anchors as currently implemented in the UI is extraordinarily narrow -- certainly not one that I have seen in the past 23 years of working with LMSes.

THIS. Please!