Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

This seems quite simple to me: Use URLs to convey app state. Zac Spitzer writes: > But what do end users or developers expect in terms of browser behavior in > this situation? > > The history api (or saving state to indexedDB) aren't going to solve the > problem of

Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

> On Jun 9, 2015, at 3:55 PM, Zac Spitzer wrote: > > But what do end users or developers expect in terms of browser behavior in > this situation? > > The history api (or saving state to indexedDB) aren't going to solve the > problem of reinitialization everytime the user

Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

I'm pretty sure it's out of scope. That's really asking to specify how OS-level task switching works. I imagine that Safari-wrapper or whatever has decided that when the OS switches back to it it will do a reload, just like when I switch back to my mail app it does a sync, and other stuff like

Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

On Mon, Jun 8, 2015 at 8:10 PM, Zac Spitzer zac.spit...@gmail.com wrote: Is it within the scope of the spec to specify whether home screen web apps should retain their loaded state when switching from foreground to background and back to foreground again? Chrome behaves exactly as expected,

Re: [whatwg] Persistent state for homescreen web apps (without reloading each time)

But what do end users or developers expect in terms of browser behavior in this situation? The history api (or saving state to indexedDB) aren't going to solve the problem of reinitialization everytime the user switches back to a web app. Users expect them to behave like a native app. The early