What is wrong with Github permalinks?

GitHub html pages, for example https://github.com/jquery/jquery#building-to-a-different-directory, have bogus permalinks. This one opens to a random place in the file (in this case a grunt command under AMD name) rather than the correct location https://github.com/jquery/jquery#user-content-building-to-a-different-directory. This happens to my files and to all other markdown files I’ve found, including the octocat spoon-knife demo where the readme is too small for bogus permalinks to cause a problem.

Is there any way to configure GitHub to create permalinks with fragments that point to the element id of the marked location?

Hello @davaya and welcome to the community.

I can’t reproduce what you’re describing. When I clicked on the first link you gave here’s what I see:

This looks perfectly aligned to me, landing at exactly the header I would expect.

Can you give some more information as to what OS version and browser version you’re using?

I’m using Chrome 86 (64-bit) on Windows 10 build 19401. Browsers behave differently to try to deal the best they can with invalid input. On chrome if the document is already open the link will scroll to the correct location. But if I click on a link in a different web page and the target page is not already open, chrome will not scroll to it.

Have you inspected the source of the GitHub pages? The element IDs are as shown above, with user-content- prepended. Those IDs are not returned by the permalink.

In URIs for MIME text/html pages such as http://www.example.org/foo.html#bar the fragment refers to the element with id=“bar”
– Wikipedia URI_fragment

To find a potential indicated element given a string fragment, run these steps:

  • If there is an element in the document tree that has an ID equal to fragment, then return the first such element in tree order.
  • If there is an a element in the document tree that has a name attribute whose value is equal to fragment, then return the first such element in tree order.

The WHATWG document has the correct element ID <h4 id="scroll-to-fragid">, and chrome correctly finds it whether or not the document is already open.

Thanks for the extra context. I’m running on macOS 10.15.7 and tried this using Safari (14.0 15610., Firefox (81.0.2), and Chrome (86.0.4240.80). I was not able to reproduce the problem using Safari or Firefox, but was able to reproduce it in Chrome. I believe this is new behavior in Chrome because I don’t recall this being an issue when I used Chrome before and it appears that user-content being prepended onto fragment IDs has been in place for at least two years.

I’ll pass along your report of this behavior to the appropriate team. Unfortunately, I can’t give an ETA on when this would be addressed.

Thanks again for reaching out and letting us know!

I see this being less about behavior and more about reliability. The fact that Chrome trips over it illustrates the fact that a problem exists, but Chrome didn’t create it.

Generating bad permalinks is a problem even if a specific collection of browsers don’t exhibit symptoms. A future standards-conforming browser not in that collection could, and non-browser html processors (think javascript libraries) certainly could.

Thanks for confirming and reporting!