memory wouldn't survive a page refresh
sessionStorage wouldn't survive a tab close
i'm not opposed to making the latter an option though
sessionStorage wouldn't survive a tab close
i'm not opposed to making the latter an option though
That isn't very common.
> sessionStorage wouldn't survive a tab close
When a tab is restored, the browser typically restores sessionStorage.
> i'm not opposed to making the latter an option though
That isn't what I was getting at. If I'm going to buy into htmx, I want to understand the design. I wondered why this was the default, and why I hadn't seen it mentioned as a security concern.
Is it guaranteed to do this? Otherwise, if it just sometimes does it, or different browsers handle it differently/may change in the future, it seems like a recipe for problems.
Chrome does, however, if the “resume where i left off” setting is enabled.
Also curious, why are you arguing so intensely for a “solution” that seems to only be worse and introduces issues as explained, without ever having stated any problem you are trying to solve with the change?
no strong opinions on session vs local storage, i was trying to make htmx act as much like the browser as possible and the browser caches across tabs
you can disable history on any page by using the hx-history attribute and you can force a server request on every history navigation by setting the htmx.config.historyCacheSize config option to 0:
SessionStorage by default with prominent placement in the docs would be better I think. It would automatically clean up the data from visitors' disk space at appropriate times, whereas the localStorage setting puts it in a place that gets persisted for quite some time.
Thanks for those links, I've read them but it's good for others here to see them.
If a website or application basically has to do the 2024 equivalent of "don't hold it that way", it's the result of a broken development model.