Proposal for an App History API
I&#x27;ve only glanced at the basics of the main proposal, so there might be details&#x2F;problems that I&#x27;m missing, but this seems pretty good.<p>Couple of things I like so far:<p>- It&#x27;s pretty narrowly scoped to a single-origin, it doesn&#x27;t try to provide a bunch of hooks around closing the browser, navigating off page, directly entering URLs. Single-origin scoping (with <i>occasionally</i> opt-in permissions to do more) should probably be the default for features like this, so it&#x27;s encouraging to see proposals with that philosophy.<p>- That very narrow scoping also allows you to do some kind of cool things like easily inspect the navigation history, without exposing a bunch of cross-origin risks.<p>- It&#x27;s asynchronous and you can interrupt&#x2F;hook around requests. This gets rid of the need to mark up every link with click handlers, which is both a win for developers and a win for users, because it means people will be more likely to just use normal in-app links rather than building their own (clumsy) navigation systems that break semantic HTML, right-clicking, and opening in-app links in new tabs.<p>- Extending on the above, having singular intercepts for in-app navigation opens up the doors for browsers&#x2F;extensions to have more control over stuff like this. I can imagine a theoretical browser preference that allowed you to mess with this list, or change how intercepts worked. In theory, it makes it easier for users to mess with things, while also making it easier for developers to build things. But that&#x27;s something I&#x27;d need to think more about.<p>I would need to read through the entire proposal in more detail to have a more concrete opinion, it&#x27;s a lot longer of a proposal than you&#x27;d expect from the title&#x2F;summary, but as both a developer and a user I like what I&#x27;ve seen so far. Seems like a low-risk feature with a number of large potential upsides.