On Sep 13, 2009, at 9:51 AM, Aryeh Gregor wrote:
As far as I know, web
apps have no way to get the user's attention if they aren't using the
web app, do they?
GMail 'blinks' by alternating the window title between two states,
which can be effective even if the animation in the window
On Sep 4, 2009, at 2:38 PM, Ian Hickson wrote:
Right. My point is the site can do that already, since we don't ever
_stop_ the site from using the local storage area. It can prompt you
for
a name directly, without UA involvement.
I'm sorry, I don't understand that. We must somehow be
On Sep 5, 2009, at 3:33 PM, timeless wrote:
In working on the n900, we've added features which generally break
javascript activity if the user is not using the web page.
...
If a client server application wants to know if the user is idle, the
algorithm is this:
If the client hasn't sent a
On Sep 3, 2009, at 6:05 PM, Francisco Tolmasky wrote:
However, I think the addition of the deferred setData methods could
be added today in a way that is completely backwards compatible with
current implementations and would still be of great benefit.
Specifically, my request for
On Sep 1, 2009, at 6:35 PM, Ian Hickson wrote:
Right now this can be done by the site directly.
You mean a download link I can click? Sure, but then the site has no
ability to access that data later unless I explicitly locate the file
and upload it. That's not the same thing as a storage
On Aug 31, 2009, at 12:04 PM, Peter Kasting wrote:
If you combine that statement with section 6.1's User agents should
present the persistent storage feature to the user in a way that
does not distinguish them from HTTP session cookies, then the
result is that, when the user requests to
On Sep 2, 2009, at 11:36 AM, Peter Kasting wrote:
It still seems like you are interpreting this statement as saying
that the UA must not allow users to keep/clear cookies separately
from Local Storage data.
Yes; that seemed the most direct interpretation of its language.
While on the
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks.
Maintaining
the user's expectations of privacy is critical.
The fact that local storage can be used as a type of
On Aug 31, 2009, at 11:18 AM, Peter Kasting wrote:
The spec says basically what you want except that it uses should.
It seems like UAs and authors would both be satisfied with this; I
don't expect any UA vendor to wantonly discard local storage data.
By encouraging the UI to treat local
On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote:
Again, the spec now says in 4.3: User agents should expire data
from the local storage areas only for security reasons or when
requested to do so by the user. The only stronger statement you
could get would be by changing this to a must.
On Aug 31, 2009, at 11:58 AM, Boris Zbarsky wrote:
It's controversial because, no offense, browser developers don't
trust the website author, nor should the users. At least to a first
approximation.
Over on another thread of this list we've already been talking about
the need to get
On Aug 27, 2009, at 5:53 PM, Dirk Pranke wrote:
Would you hold a different opinion for different types of HTML5-based
applications (like the TiddlyWiki app that gets copied locally)? Or
would you require that all apps go through an install process that
acquires quota, permissions, etc.?
On Aug 28, 2009, at 3:40 PM, Jonas Sicking wrote:
Seems like an event would be a better solution. For example fire a
'idlestatechange' event with the following API:
Such an event implies one specific time interval that denotes 'idle'.
Different clients are likely to want to use different
[This is a spin-off of Web Storage: apparent contradiction in spec.
I'm starting a new thread to make a specific proposal.]
I agree that where possible we should find a way to do things without
adding Mother-may-I dialog boxes. But I also believe we need some user
interaction to enable a
On Aug 26, 2009, at 3:10 AM, Anne van Kesteren wrote:
Indeed. It would be nice to be able to write simple applications
that do not require the cloud at all and basically consist of a set
of static documents distributed over HTTP.
TiddlyWiki is a perfect example of this, if anyone's
I know that one of the design issues with worker threads and local
storage has been how to resolve concurrency issues, and that for this
reason, in the current spec worker threads can't access local storage.
However, there's a scenario under the current spec that doesn't
involve local
On Aug 26, 2009, at 2:11 PM, Drew Wilson wrote:
My recollection is that we prohibit worker access to cookies for
exactly this reason (WorkerGlobalScope does not expose a cookies
attribute).
Looks like you're right; section 5 of the Web Workers spec says:
The DOM APIs (Node objects,
On Aug 26, 2009, at 4:01 PM, Linus Upson wrote:
The analogy was made comparing a user agent that purges local
storage to an OS throwing out files without explicit user action.
This is misleading since most files arrive on your computer's disk
via explicit user action. You copy files to
On Aug 26, 2009, at 4:55 PM, Michael Nordman wrote:
What seems inevitable are vista-like prompts to allow something (or
prods to delete something) seemingly unrelated to a user's
interaction with a site... please, oh please, lets avoid making that
part of the web platform.
Doesn't Gears
I've just noticed an apparent self-contradiction in the Web Storage
spec (24 August draft).
Section 4.3 states:
Data stored in local storage areas should be considered potentially
user-critical. It is expected that Web applications will use the
local storage areas for storing user-written
Interesting comments. Linus and Jeremy appear to be coming at this
from a pure cloud perspective, where any important or persistent
data is kept on a remote server and the browser, so local storage can
be treated as merely a cache. That's definitely a valid position, but
from my
21 matches
Mail list logo
