-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broken anchor links within markdown documents #1627
Comments
+1 this is obviously a bug. If someone would like an example of the issue, check out my app where I use this package's output to render a repo's readme https://www.starter.place/jihchi/vitejs-template-react-rescript#vite-react-rescript-starter |
The When using the custom anchor with a URL fragment (e.g. You could of course add the I have created https://github.com/orgs/community/discussions/50962 asking if there is official support for custom HTML anchors, or if this just happens to work. Though maybe there is a better place for that question. |
Stale issue message |
Bug still present message |
Stale issue message |
Bug still present message |
Example: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-introduction
Anchor links to this document are commonplace elsewhere on the Internet, and are used extensively within the document itself. However it appears that somewhere in the github rendering pipeline an additional prefix is being inserted which breaks things.
An example link to the introduction section from within the markdown source:
The introduction section anchor target in the markdown source:
# <a name="S-introduction"></a>In: Introduction
The rendered link:
The rendered target (with some pretty-printing):
There are two problems with this:
user-content-in-introduction
, but then an href of#in-introduction
. Prefix or not doesn't especially matter (unless someone has already externally copied such a link) but these do need to be the same.<a name/>
anchor explicitly specified in the markdown source has also erroneously had auser-content-
prefix added to it, which is absolutely a bug.So the quick fix might be to find and boot whatever is adding those prefixes, though that may not be the best fix depending on the history.
The text was updated successfully, but these errors were encountered: