Community Wishlist Survey 2022/Reading/Automatically visit the corresponding URL without the section

Automatically visit the corresponding URL without the section

  • Problem: When one visits "Page#Section", links to "Page" will still be colored blue (unvisited) rather than purple (visited).
  • Proposed solution: When one visits a section of a page directly (from the address bar or browser history, whether it be MS Edge, Google Chrome, or Mozilla Firefox), via a redirect or link from another page, or after saving a section edit, briefly redirect to the URL without the "#Section" part before jumping to the section. Such brief redirection should not be done if the link is to another section of the same page (in particular, if the link is from the TOC).
  • Who would benefit: Everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: GeoffreyT2000 (talk) 16:49, 15 January 2022 (UTC)

Discussion

  • So... make the site slower to appease this aesthetic? No, no thank you. --Izno (talk) 20:13, 18 January 2022 (UTC)
    I do understand the idea of the wish and also agree that it would be beneficial for user experience to know which sections one has already visited and read through. @Izno do you know of any additional performance limitations that come with this? My worry would be, assuming this is a CSS change using the :visited pseudo class, that this would be privacy issue like described in https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector KSiebert (WMF) (talk) 10:41, 19 January 2022 (UTC)
    :visited already does display a different color for non-section links. The specific issue I have is the "add in a redirected page", which is decidedly a performance degradation (visiting 3 pages instead of 2 to get to the final location of the section). Izno (talk) 18:39, 19 January 2022 (UTC)
    We could perhaps add a click handler to "Page#Section" links and use History.pushState() to simulate "Page" as having been visited, and that would come with no performance degradation. However then hitting the browser's back button would first go to "Page" and would require a subsequent click to actually go back to where you were previously, which would be pretty odd from a user perspective. I'm not sure if using History.replaceState() or something else could get around that problem. MusikAnimal (WMF) (talk) 20:41, 27 January 2022 (UTC)
    I ran some tests and this seems doable. The better route I think would be to use History.replaceState() after the page has loaded, first replacing the URL without the hash ("Page") then quick re-replacing it so the URL is where you currently are ("Page#Section"). This avoids polluting the browser's history but still registers the URL as if it were visited. It feels a little hacky, but it seems to work! I'm not certain if this will fly as a feature built right into MediaWiki Core, but we could at the very least offer a gadget or something to do this. MusikAnimal (WMF) (talk) 00:30, 28 January 2022 (UTC)

Voting

  •   Oppose I prefer the current functionality. Libcub (talk) 23:21, 30 January 2022 (UTC)
  •   Oppose Also like Libcub Thingofme (talk) 13:32, 1 February 2022 (UTC)
  •   Oppose KingAntenor (talk) 06:55, 2 February 2022 (UTC)
  •   Oppose per above. I prefer as it is now.- Darwin Ahoy! 00:45, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 03:29, 6 February 2022 (UTC)
  •   Oppose Ayumu Ozaki (talk) 00:45, 7 February 2022 (UTC)
  •   Support We could make such functionality optional and configurable in user preferences if wanted. Lectrician1 (talk) 05:26, 6 February 2022 (UTC)
  •   Oppose DSparrow14 (talk) 17:56, 11 February 2022 (UTC)