[HN Gopher] Proposal for an App History API
       ___________________________________________________________________
        
       Proposal for an App History API
        
       Author : dfabulich
       Score  : 28 points
       Date   : 2021-02-03 20:35 UTC (2 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | danShumway wrote:
       | I've only glanced at the basics of the main proposal, so there
       | might be details/problems that I'm missing, but this seems like a
       | good proposal.
       | 
       | Couple of things I like so far:
       | 
       | - It's pretty narrowly scoped to a single-origin, it doesn't try
       | to provide a bunch of hooks around closing the browser,
       | navigating off page, directly entering URLs. Single-origin
       | scoping (with _occasionally_ opt-in permissions to do more)
       | should probably be the default for features like this, so it 's
       | encouraging to see proposals with that philosophy.
       | 
       | - 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.
       | 
       | - It's asynchronous and you can interrupt/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.
       | 
       | - Extending on the above, having singular intercepts for in-app
       | navigation opens up the doors for browsers/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's something I'd need to
       | think more about.
       | 
       | I would need to read through the entire proposal in more detail
       | to have a more concrete opinion, it's a lot longer of a proposal
       | than you'd expect from the title/summary, but as both a developer
       | and a user I like what I've seen so far. Seems like a low-risk
       | feature with a number of large potential upsides.
        
       | bonestamp2 wrote:
       | This is probably more of an adgecase, but it would be nice...
       | access to an array of the last 10 items in the history (for the
       | same domain in the same tab).
       | 
       | Yes, of course you can store that data in application memory, and
       | that's what we currently do (we send it with runtime exception
       | errors so we can try to reproduce the problem). But, it would be
       | nice if that function was inherent to the browser instead of
       | everyone downloading that code in all of our applications. Then
       | it could persist through page refreshes too.
        
       | zaczekadam wrote:
       | It seems to be gaining some traction. Link to the proposals repo:
       | https://github.com/WICG/app-history
        
       ___________________________________________________________________
       (page generated 2021-02-03 23:01 UTC)