-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Hash links to new pages don't focus the correct element #3770
Comments
Maybe related #3636 |
Still believe it's related to the problem I mentioned in #3105. And I don't think it's covered together with the scrolling. As for what we can manage focus. We can't just Unfortunately, there seems to be no way to programmatically set the Sequential Focus Navigation Start Point. These are the possible workaround I can think of:
|
I came here to post an article about SFNSP I just stumbled upon — https://hiddedevries.nl/en/blog/2017-04-24-where-focus-goes-when-following-in-page-links — but it basically just reiterates what @jasonlyu123 posted. All three strategies seem viable:
|
Just spitballing, but would it be possible for us to manually set the hash after navigation? Something like:
|
Apparently even a simple |
Yeah. seems like only calling I found some downside with navigation approaches. The history entry would be replaced. So the new history entry won't have a If this turns out to work in safari and we can solve the history problems. It seems like a good approach to do. |
location.replace will also make CSS :target work after navigation. Currently :target doesn't work when navigated to a new route with a hash. |
Is this issue open for contributors? Can I open a PR for this? |
The reproduction link is outdated, todos section of it is throwing error. @Rich-Harris , is this bug still exists? |
For anyone interested, this works for me as a temporary workaround: onMount(() => {
const hash = window.location.hash.slice(1);
if (hash) {
window.location.hash = hash;
}
}); Edit: apparently that's not how the spec says it behaves, however, it works fine for me. |
I noticed there is Previous code:
Using |
After more testing it looks like there's no need for neither |
Alas, Firefox still needs manual replaceState(). Chrome seemed fine without. |
This doesn't seem to work on macOS Safari. Might be because of Safari's behaviour of waiting for the actual user's first click and not recognising programmatic clicks. Unless we leave Safari out, this option does pretty well. |
Describe the bug
If you click a link like
<a href="#foo">
, the browser will focus an element like<h2 id="foo">
, which in effect (since<h2>
elements aren't typically focusable) actually means that pressingTab
will focus the next focusable element after the<h2>
.But if you click a link like
<a href="/other#foo">
, SvelteKit will navigate to/other
and scroll to#foo
, but it won't focus the element.Reproduction
https://stackblitz.com/edit/sveltejs-kit-template-default-nrjdx2
Logs
No response
System Info
Severity
serious, but I can work around it
Additional Information
No response
The text was updated successfully, but these errors were encountered: