Should modal-close buttons execute history.go(-x) instead of pushing to the history stack?

[hirasso]

User expectations for classic modals are that they overlay the main content and thus won't push to the history stack when being opened or closed.

For presentational websites, where the main content is only presented like a modal, this paradigm is not true. People might want to link directly to the detail page, making it necessary to actually serve the overlay with it's own dedicated URL.

Describe the problem

On the demo site, follow this path:

• click on "Characters"
• open one of the characters
• close the character using the UI (x)
• click the browser's back button

Current behavior

The browser re-opens the overlay.

Expected behavior

The browser should go back to the home page.

Describe the proposed solution

Ideally, we would find a way to keep track of the point in history from where a modal was opened. Then when clicking the close button, fragment-plugin could execute history.go(<negativeHistoryOffset>) to close the modal, instead of just pushing to the history stack.

We can probably make use of the history index, that is also being used for detecting the direction of travel: https://swup.js.org/visit/#identify-history-visits

How important is this feature to you?

• Since this could potentially annoy/confuse visitors, I'd love to find a solution before the first 1.0 release

[ovenum]

For me, in the context of the demo site, the current behaviour should be the expected behaviour.
The model/dialog opens an article that has it’s own url and should push it to the history stack. This allows to navigate between articles with back-forward navigation.

Overlays/modals/dialogs that actually contain a dialog, asking the user to make a choice or just contain a notification are imho not the scope of the fragments plugin and should be dealt with at another level.

[benozol]

Maybe the problem in the demo is just the [X] (as usual these days…): it suggests that the overlay is a dialog. if it's a dialog it would replace without history/URL (I think), so navigating back after close wouldn't reopen it. but if the main content overlay must have a close button, then history.go(-x) would result in a more intuitive navigation history, agreed with @hirasso. but why would the main content overlay have a close button in the first place? why not rely on browser navigation to go back to the previous content as usual?

[hirasso]

Thanks @ovenum and @benozol for both your input!

I'm leaning a little bit more towards the opinion of @ovenum – obviously, since I also built the demo site as it is 😁

Of course, using a dialog/modal in the classic way and without it's own URL would still possible, Fragment Plugin won't stop anyone there.

Swup's core concept is that every page has it's own URL. Fragment Plugin follows this principle, only making new UX patterns possible. Is that innovative? Is it confusing? You choose... :)

[hirasso]

Finally, I can use the poll function 🎉😄

[daun]

Could this be configurable? I'm strongly in favor of pushing to the history stack, but I can imagine scenarios where it's the other way around. Probably depends a bit on the specific design and navigational concept of the site in question. When in doubt, make it an option 😎

[hirasso]

Yes, I'm all in making this configurable if there is enough interest in the feature. Sadly we are in the browser and must always keep the bundle size in check 😱😄