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

[Nils Dagsson Moskopp]

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 reinitialization everytime the user switches back to a web app.
> Users expect them to behave like a native app.
>
> The early iPads were low powered devices and many app developers used to
> ship content as  images because they couldn't render complex layouts
> quickly, but newer tablets are far more powerful and can handle this.
>
> Chrome handles this as users and developers expect, web apps get paged out
> and require a reload depending on memory etc. Safari does it every single
> time
>
> This is a massive barrier against web apps competing against native apps.
> On 10 Jun 2015 6:21 am, "Domenic Denicola"  wrote:
>
>> 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
>> that.
>>
>> > -Original Message-
>> > From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Zac
>> > Spitzer
>> > Sent: Monday, June 8, 2015 21:10
>> > To: wha...@whatwg.org
>> > Subject: [whatwg] Persistent state for homescreen web apps (without
>> > reloading each time)
>> >
>> > 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, however, iOS reloads the web app
>> > each time
>> >
>> > http://zacster.blogspot.com.au/2015/04/broken-web-apps-launched-from-
>> > ios-home.html
>> >
>> > --
>> > Zac Spitzer
>> > +61 405 847 168
>>

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Nils Dagsson Moskopp]

David Sheets  writes:

> On Sun, Feb 15, 2015 at 3:16 AM, Glenn Maynard  wrote:
>> On Sat, Feb 14, 2015 at 12:34 PM, David Sheets  wrote:
>>>
>>> I am writing a documentation generation tool for a programming
>>> language with right arrows represented as -> but would like to render
>>> them as →. Programmers are used to writing in ASCII and reading
>>> typeset mathematics. If I present documentation to them via a
>>> purpose-built document browser, I should give them the option (at the
>>> generation/styling stage) of making those documents as pleasing as
>>> possible.
>>
>>
>> Programmers a decade or two ago, maybe, but not today.
>>
>> As a programmer, if I see "→" on a page, select it and copy it, I expect to
>> copy "→", just as I selected.  This sounds like something browsers should
>> actively discourage.
>
> If you're reading documentation which includes types, it's nice to see
> implication arrows but copy valid syntax.

If you are reading documentation, it is nice to see valid syntax. What
if the user is typing the documentation? I can type “→” easily by using
a compose key and would be confused if it does not work in the language.

> Programming communities which use types or other formal methods
> commonly typeset their own documents with mathematical notation. For
> practical reasons, they define their language representations using
> ASCII.
>
> If you have nothing more useful to discuss beyond uninformed,
> opinionated naysaying, I'll be leaving this thread lie.

I find that last paragraph entirely superfluous.


Greetings,
-- 
Nils Dagsson Moskopp // erlehmann

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

[Ryosuke Niwa]

> 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 switches back to a web app.
> Users expect them to behave like a native app.

That seems like a very platform/product specific issue to me.  I don't think we 
want W3C to be mandating how Web browsers should interact with the rest of the 
system.

> Chrome handles this as users and developers expect, web apps get paged out
> and require a reload depending on memory etc. Safari does it every single
> time

By Chrome, do you mean Android?  Again, this is really about the 
platform-dependent behavior we shouldn't be spec'ing in W3C.

Please file a new bug on our bug tracker at http://radar.apple.com

- R. Niwa