Sapper: Anchor tags cannot be accessed from other pages

[alizauf]

Navigation to an anchor link from another page doesn't work, and only takes you to the top of the page. However, navigation to an anchor link does work if you are already on the page.

I encountered this issue when trying to create drop-down top navigation items that take you to an anchor within another page.

You can reproduce the error here: https://github.com/alizauf/another-anchor-test

This may be related to https://github.com/sveltejs/sapper/issues/331 (and thanks @mhkeller) for a convenient sample repo to easily demonstrate.

[paulocoghi]

@Rich-Harris, correct if I'm wrong on this issue.

I believe that Sapper uses roadtrip (or part of it) for routing. Roadtrip is made with some inspiration from page.js and both of them suffer from this issue.

I am with the same problem but I have not had enough time to address this issue yet, and I'm starting to dig on this issue right now.

If I find a solution, I will happily do a PR to both page.js and sapper, as I've done before (on page.js and sapper).

[paulocoghi]

@Rich-Harris if I submit a PR to roadtrip, is it easy for you to re-adapt it to sapper?

[Rich-Harris]

@paulocoghi I think I might have just yanked the code from roadtrip/page that filtered out anchor tags that the router shouldn't be concerned with — they're not in sync or anything. But if there's a fix that works for one then hopefully it'll work for all...

[paulocoghi]

@Rich-Harris, here are my current findings:

• my fork of page.js is based on v1.7.1, and it wrongly prevents hash navigation both on the same page and when you are coming from a different page
• in Roadtrip and/or Sapper, you have partially solved the problem, as hash links in Sapper works at least when you are on the same page

My temporary solution is to call scrollIntoView¹ inside the router, because:

• we are already preventing the default hash navigation, on one situation (Sapper/Roadtrip case) or both (my case)
• if we prevent on both, we can programmatically check if we are on the same page and:
  
  
  
  • if we are, call scrollIntoView to the element with the id used on the hash link
  
  
  • if we aren't on the same page, proceed with the navigation to the other route and, after completion, call scrollIntoView
  
  

---

¹ 93+% browser support when not using the smooth option

[paulocoghi]

I need more time to infer if it is possible to improve our routers' logic in a way where we don't need to call anything and succeed in all possible navigation cases.

Until then, I believe that using scrollIntoView is probably the best solution.

[Rich-Harris]

Fixed by @DayBr3ak in 0.23.1!

[alizauf]

Hurray! Thanks @DayBr3ak !