Restore focus to persisted element after replacing content #901
Conversation
|
Hi @ovenum 👋 Thanks for contributing! I agree about things working as you're suggesting for the input use case. I'd like to ponder this some more with other scenarios in mind, e.g. a persisted link element with a shopping cart counter which navigates to the shopping cart page. My feeling is that I'd like the focus here to be reset to the body as on normal visits. Maybe we can limit this to |
|
@hirasso What's your opinion on this? With just the core in mind, this sounds like a good idea, no? Where it confuses me is the a11y stuff — we'd 1) lose focus 2) refocus the input 3) reset focus to the body. Might be confusing, but it also might just be debounced and totally fine. I'd suggest limiting this to inputs to keep this specific. |
|
There could be another issue with persisted elements having client state that is only tracked in JS and input elements inside these elements. For example a persisted section nav-bar with filter menus and a search input. If focus is only re-applied to input elements, it could be enough to also search the child elements of the persisted element for input elements. How would this work with WebComponents that extend on Input elements? |
|
Thank you @ovenum for bringing this up! I have recently been fighting with a very similar use case, as well. I ended up not persisting my filter nav but rather managed as much state as possible on the server, and restored the focus using a custom hook and @swup/a11y-plugin (which provides custom handling of swup.hooks.before("content:replace", (visit) => {
const focusID = document.activeElement?.getAttribute("data-focus-id");
if (focusID) {
visit.a11y.focus = `[data-focus-id="${focusID}"]`;
}
});That way, I can control from my markup if the focus on an element should be restored when navigating: <!-- restore focus to this element if it had focus before the visit -->
<input data-focus-id="unique-id" type="text"></input>While thinking about focus, we have to keep in mind, that the expected behavior for screen reader users is that the focus is always set to the If we decide to proceed with this, It could be helpful to revisit what Astro decided to do with focus in their Regarding the (Alpine.js?) state: usually, morphing and persisting is exactly meant for persisting state. (see Alpine.js' Morph Plugin or the headline in the Astro docs ("Maintaining State"). I think this is a hard problem that I'd love to discuss in a call between the three of us sometime soon, where we can look at our real-world use cases together and discuss if this can be generalized somehow without silently breaking anyone's implementation. It might turn out to be the cleanest solution to introduce a new attribute |
|
As discussed, we are closing this for now. Users can easily implement their own solution using a hook as described above. We should keep in mind to think about merging swup/a11y-plugin into core, to make accessibility a first class citizen in swup's ecosystem. |
This PR restores focus to a DOM Element persisted with
data-swup-persistif it was the focused element before content replacing took place.This is useful for input elements that trigger a search and should remain focused when the result is added to the DOM.
To further illustrate what this PR tries to solve please see the example on replit here
Checks
masterbranchnpm run lint)npm run test)Additional information
data-swup-persistshould reflect that focus is persisted.