You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since #9477 the web interface adds a "user-content-" prefix to IDs in markup files.
The internal links [link to internal anchor](#my-anchor) are correctly updated with the prefix, but links to an anchor of another file are not. This makes the link point to a non existing ID and navigation ends up at the top of the other page.
This breaks navigation between long markup files.
Tested with markdown files in repository, and in the wiki pages, as you can see in the test repo https://try.gitea.io/annelauref/TEST_prefix_ID
I think a solution would be to add the prefix to anchors in relative links.
Edited to say: manually adding user-content- to links between file could be a workaround for some repos but it is confusing (needed for some links but no all) and breaks compatibility with at least Github (for me it's happening on a repo that has multiple remotes, one on an internal Gitea server and one on Github)
Screenshots
As you can see in this image, this link is not rewritten:
But the anchor in the other file is rewritten:
The text was updated successfully, but these errors were encountered:
Oh great, I tried searching everywhere but obviously didn't use the right keywords. Thank you for pointing me to the right place.
I'll wait patiently for 1.13.0 then :)
Yes, #11903 will make anchors from URL work with and without the user-content- prefix. The feature does require JS to be enabled, but that applies to GitHub's links too.
This changes the links on headings like '# Usage' in markdown from
`https://host/user/repo#user-content-usage`
to just
`https://host/user/repo#usage`
matching GitHub and GitLab. The linked id elements still have the prefix
and this behaviour matches GitHub and GitLab too, so JS is needed to
scroll to the active anchor. I suspect it's like that to avoid namespace
collission between user-generated content and other page content.
Compatibilty for old links is included so they will continue to work.
Also included are some enhancements to make the clickable area for the
link icon larger and fix its color on arc-green.
Fixes: go-gitea#11896Fixes: go-gitea#12062
This changes the links on headings like '# Usage' in markdown from
`https://host/user/repo#user-content-usage`
to just
`https://host/user/repo#usage`
matching GitHub and GitLab. The linked id elements still have the prefix
and this behaviour matches GitHub and GitLab too, so JS is needed to
scroll to the active anchor. I suspect it's like that to avoid namespace
collission between user-generated content and other page content.
Compatibilty for old links is included so they will continue to work.
Also included are some enhancements to make the clickable area for the
link icon larger and fix its color on arc-green.
Fixes: go-gitea#11896Fixes: go-gitea#12062
[x]
):Description
Since #9477 the web interface adds a "user-content-" prefix to IDs in markup files.
The internal links
[link to internal anchor](#my-anchor)
are correctly updated with the prefix, but links to an anchor of another file are not. This makes the link point to a non existing ID and navigation ends up at the top of the other page.This breaks navigation between long markup files.
Tested with markdown files in repository, and in the wiki pages, as you can see in the test repo https://try.gitea.io/annelauref/TEST_prefix_ID
I think a solution would be to add the prefix to anchors in relative links.
Edited to say: manually adding user-content- to links between file could be a workaround for some repos but it is confusing (needed for some links but no all) and breaks compatibility with at least Github (for me it's happening on a repo that has multiple remotes, one on an internal Gitea server and one on Github)
Screenshots
As you can see in this image, this link is not rewritten:
But the anchor in the other file is rewritten:
The text was updated successfully, but these errors were encountered: