behavior of anchored/hash links in Framework

[shadoof]

I am now a keen user of Framework and am refining a project which integrates notebooks on Observable with a Framework-built site (= live updating of a static site). I have noticed that links of the form:

1. [<linked text>](#<named cell>) and
2. [<linked text>](<file or notebook>#<named cell> operate differently in Observable and Framework.

• links of form 1 work in both Observable and Framework - auto scroll jump to named cell
• links of form 2 work differently:
  • on Observable you go the notebook and auto scroll jump to named cell
  • on Framework you just go to the top of the indicated file

It would be desirable to always and consistently have the auto scroll jump to named cell work in Framework.

[shadoof]

I realize that what I said above was out of a context that is specific to a project of my own and have changed the title of this (so-far) more or less unnoticed discussion.

But there is a general problem – possible bug – with anchored links in Framework.

• When a Framework page is open, Markdown links of the form [<linked text>](#<id>) will scroll to a div with the requested id.

But ...

• From another Framework page in the same project, Markdown links of the form [<linked text>](<pageName>#<id> will NOT. They only link to the top of the <pageName> page.

Even though ...

• If the same form of link is used from outside the Framework project, e.g. <projectUrl>/<pageName>#<id> the requested Framework page WILL sometimes scroll to a div with the same id. (I say 'sometimes' because sometimes the hash linked url has to be submitted twice or edited before the scroll-to behavior works. I really do not understand the behavior or how to reproduce it consistently.)

[mbostock]

The behavior of #id scrolling to a DIV element with the specified id is something implemented natively by browsers, not by Framework. If it’s not working when you click on a link from another page, it could be because the DIV that you are trying to scroll to is generated dynamically via JavaScript after load and thus it doesn’t exist on the page the instant the page loads. Observable notebooks have some custom code that compensates for this (by repeatedly trying to scroll to the requested cell if a #id is detected), but Observable Framework doesn’t have any such logic (yet) — so you’re just seeing the native behavior of browsers. If possible, I recommend only linking to static elements (i.e., those you’ve written in HTML or Markdown, in a .md file) rather than content created dynamically with JavaScript; this way the link will work with the browser’s native behavior.

[shadoof]

Many thanks and sorry about the confusion. Makes sense. The behavior I reported is indeed produced while or before dynamic content is being Javascript-generated. I'll work on a workaround for myself, for the time being.

[shadoof]

@mbostock and anyone interested. I solved this problem (definitely happens in Chrome but not in Firefox) with this little workaround hack:

let hashLinkChecks = 0;
const hashLinkLoader = setInterval((checksLimit = 2) => {
  let div = document.getElementById(window.location.hash.substring(1));
  if (div) {
    div.scrollIntoView();
    clearInterval(hashLinkLoader);
  }
  if (++hashLinkChecks >= checksLimit && !div) clearInterval(hashLinkLoader);
}, 100);