Anchor links copied from project READMEs now add a ?tab=readme-ov-file query parameter, making them harder to read

[pirate]

Select Topic Area

Product Feedback

Body

When copying anchor link to a specific section in a project's README, the URLs now contain an extra query parameter indicating the tab: ?tab=readme-ov-file, e.g.:

https://github.com/ArchiveBox/ArchiveBox?tab=readme-ov-file#quickstart

I understand why this is needed for other tabs, but it adds unnecessary clutter and makes links harder to read for the most common default case of linking to a section of the README.

The parameter can be manually deleted form the URL and it still works the same, but this extra cleanup work is something most people wont do. With the current default, we'll end up with tons of links shared around the internet that look like this:

https://github.com/ArchiveBox/ArchiveBox?tab=readme-ov-file#quickstart

instead of this:

https://github.com/ArchiveBox/ArchiveBox#quickstart

You can already see them starting to spread: https://www.google.com/search?q=%22readme-ov-file%22

If the UI/web team would kindly consider removing this parameter in the default case I think it may improve the link sharing UX for everyone! Github is doing such an awesome job lately with all the new features, I really appreciate the new tabs feature aside from this nit, and thank you to whoever ends up taking a look at this change!

[vogler]

It adds ?tab=readme-ov-file on any click in the README and rewrites history which is just terrible:

Screen.Recording.2024-01-20.at.21.28.46.mov

[RokeJulianLockhart]

https://github.com/orgs/community/discussions/70577#discussion-5754901

@pirate, I don't see why its inclusion is problematic, because your explanation is rather vague — how is it confusing?

[RokeJulianLockhart]

https://github.com/orgs/community/discussions/70577#discussioncomment-8269223

@pirate, I don't agree. For instance, when even the name of the ReadMe file itself has changed, ?tab=readme-ov-file is better, due to it demonstrating to the user that the user is being focused upon the ReadMe file. This is useful because then the fragment (#)-delimited section demonstrates that it refers to a heading. However, I agree that ultimately it is flawed — because it's not fragment-delimited, instead an argument, I expect that it's processed server-side. This appears nonsensical to me, because the entire page is loaded regardless. Were it not, it would be a performance improvement too.

Regardless, I've realized that usually, linking to https://github.com/ArchiveBox/ArchiveBox/blob/22aae92e959c4758ea4fc57dcd62ee757de14682/README.md instead is better, because most references to a ReadMe refer to information best correlated to the version relevant to the reference.

[vogler]

Come on... This just adds unnecessary noise for 99% of uses (notes, people sharing links to projects). See my video above - it even adds this when you don't link to a heading. Even if, the default tab shouldn't have any parameters, ?tab=coc-ov-file etc. are fine.

Whether to use permalinks is a different topic and depends on the context.

[fenn]

it also breaks uniqueness of the repository URL. now there are two URLs that point to the same place, which can result in duplicate bookmarks, problems with internet archive captures, and so on.

[silverwind]

Definitely get rid of that ugly param for the readme tab. It's just polluting the URL with unnecessary info.

[ioRekz]

I'm playing with a browser prototype that struggle with that (and probably a lot more things 😅) because github readme -> click link -> browser back button returns to a different URLs which my prototype can't differentiate from a entirely new page. Anecdotical on my case but might surface similar issues

[vogler]

Here's a quick fix using Tampermonkey: https://gist.github.com/vogler/74edff6de37c3a13eeff8c99c6bed910
It removes ?tab=readme-ov-file from the URL and anchor links still work.
If you want ?tab=readme-ov-file included in the URL, just click on the same anchor link twice.

    const rewrite = () => location.search == '?tab=readme-ov-file' && (console.log('rewrite', location.href) || history.replaceState({}, null, location.href.replace(location.search, '')));
    window.onpopstate = rewrite; // on navigation
    rewrite(); // on initial load

[silverwind]

Works in Violentmoney as well and I think if you add .user.js extension to your gist filename it should be one-click installable from the raw link in all userscript managers.

[evdcush]

The amount of Tampermonkey scripts needed to restore basic, prior UX to GitHub is getting silly...

Have an issue with the new bigbrain UI/UX changes?
Did GitHub break prior functionality and support and ignore bug reports?

For instance, markup rendering for the native file format of Python documentation (reStructuredText):

• https://github.com/orgs/community/discussions/86715
• https://github.com/orgs/community/discussions/121163

GH: Lol, not Copilot related 🤣

[phanirithvij]

There's also refined-github extension, it adds useful improvements to github UX, refined-github/refined-github#6904

[westurner]

When sharing GitHub URLs on sites that abbrevi... links, it's really frustrating to not be able to read the url because there's an unnecessary ?tab=readme-ov-file before the URL fragment:

github.com/org/repo?tab=readme-ov...
github.com/org/repo#readme-heading

This was an original GitHub feature; clean deeplink urls for README headings

[yuis-ice]

I use a highlighter browser extension which heavily depends on URL and params, which is the problematic part at least for me.

[ryuheechul]

I'm curious... what does ov (in readme-ov-file) even stand for? Anyone knows?

[pirate]

I'd guess "open view"