- From: Nick Coury <notifications@github.com>
- Date: Thu, 11 Jan 2024 08:58:41 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/921/1887579651@github.com>
This would be a greatly welcome addition. I prototyped an MPA VT experience a couple months ago and this was the biggest blocker to it working. I tried several versions of saving navigation timestamps in history and/or navigation state entries on page load, and looking up the most recent previous page to determine the index and direction. It was unreliable. From my notes, sometimes the timestamps saved to entries forward in the navigation stack would disappear. I'm not sure if this was a browser bug or internal logic from another team, as I was building it into a large production app. Regardless, it can be buggy and unreliable to depend on this approach whereas the browser always knows the truth. My animation was an iOS-style slide of the new page in/out, and sometimes a back navigation would play the forward slide which would be extremely disorienting for users. If I recall, it was also slightly painful to coordinate across full page loads and bfcache navigations. At minimum, I'd want to have the size and direction of the jump, e.g. -1 for back, 0 for refresh, 1 for forward, larger numbers for multi-jumps. This is easy enough with the explainer proposal. It might be useful to have convenience fields for `jumpSize`, `isBack`, etc. if it is acceptable to increase API size. Otherwise developers will all implement similar boilerplate e.g. https://twitter.com/matthewcp/status/1734947279167955253 -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/921#issuecomment-1887579651 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/921/1887579651@github.com>
Received on Thursday, 11 January 2024 16:58:47 UTC