Re: [whatwg] Text areas with pattern attributes?
Smylers wrote: The point is to have cases specifically _for_ it -- not adding everything for which there isn't a reason against. If textarea pattern=... wouldn't in practice be used by authors then there's no point in adding it. If it would be used then it should be trivial to show some places where it would be used. I think it's important not to forget that a great deal of web applications are internal applications not exposed to the Internet. In an environment like that performance issues with evaluating regexps against a large body of text are less of an issue, since the workstations used are under the control of the organization the application is internal to. Personally I just feel that a unified interface is more valuable than holding author's hands and preventing them from making unwise design choices. If an input field used with the pattern attribute for inputting a single value needs to be changed to a multi-line textarea with the same pattern repeated not having pattern for textareas would mean a great deal of extra work for authors. Granted, my judgement is clouded... I've always felt that the separation of input type=text and textarea seemed unnatural. I guess I'm just personally against widening the gap when the difference from a user's perspective is that one is single-line and the other multi-line. :) .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Adding alpha channel to input type=color
Victor Vasiliev wrote: I suggest to add a boolean attribute alpha to input type=color (disabled by default). If this attribute is present, the color well allows to set opacity value, and instead of sRGB, sends RGBA. Another question is which format should be used to submit RGBA color. We have rgba(number, number, number, float) used in canvas, but I feel like it's not the best format to be used in submited data. Maybe #rrggbbaa or #aarrggbb? input type=color is specified to define a simple color: http://dev.w3.org/html5/spec/Overview.html#simple-color While alpha information is useful, it's not really a color attribute is it? Using type=color paired with type=range for alpha would serve fairly well in most cases, I believe. How do the people more into design feel about this? I'm mainly a coder myself. .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Storage mutex
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.orgwrote:
First of all, I was wondering why all user prompts are specified as
must release the storage mutex (
http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this
really say must instead of may? IIRC (I couldn't find the original
thread, unfortunately) this was added because of deadlock concerns. It
seems like there might be some UA implementation specific ways this could
deadlock and there is the question of whether we'd want an alert() while
holding the lock to block other execution requiring the lock, but I don't
see why the language should be must. For Chromium, I don't think we'll
need to release the lock for any of these, unless there's some
deadlock scenario I'm missing here.
So if one page grabs the lock and then does an alert(), and another page
in the same domain tries to get the lock, you're going to let the latter
page hang until the user dismisses the alert in the first page?
Yes. And I agree this is sub-optimal, but shouldn't it be left up to the
UAs what to do? I feel like this is somewhat of an odd case to begin with
since alerts lock up most (all?) browsers to a varying degrees even without
using localStorage.
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already pretty
bad), because it willl make applications in visually unrelated tabs and
windows hang.
You can have script connections that span multiple tabs in multiple windows,
so in order to preserve the run-to-completion semantics of JavaScript, it is
important that window.{alert,confirm,prompt,showModalDialog} be modal across
all windows in the browser. This is why those APIs suck rocks, and we
should never create APIs like them again.
Given that different UAs are probably going to have
other scenarios where they have to drop the lock (some of them may even be
purely implementational issues), should we add some way for us to notify
scripts the lock was dropped? A normal event isn't going to be of much
use,
since it'll fire after the scripts execution ends (so the lock would have
been dropped by then anyway). A boolean doesn't seem super useful, but
it's
better than nothing and could help debugging. Maybe fire an exception?
Are
there other options?
A generation counter might be useful.
Ooo, I like that idea. When would the counter increment? It'd be nice if
it didn't increment if the page did something synchronous but no one else
took the lock in the mean time.
Defining no-one else may be difficult. I haven't thought this through, to
be honest, but I think you could update the counter every time the storage
mutex is released and the shared state was modified since the storage mutex
was acquired. Reading the counter would acquire the storage mutex. You'd
basically write
var counter = window.storageMutexGenerationCounter;
... do lots of stuff ...
if (window.storageMutexGenerationCounter != counter) {
// abort, or refresh local state, or something
}
I'm not sure what you'd do if you discovered an undesired lock-drop,
though. If you can't write something sensible instead of abort, or
something, it's not worth doing.
Implementation-wise, the easiest thing to support is a boolean that becomes
true when the lock is release and false when the lock is acquired. Trying
to update a counter based on modifications to the local storage backend
which may be happening on another thread seems like more effort than it is
worth.
But, what would you call this boolean? storageMayHaveBeenUpdated? :-P
I'm struggling to find a good use case for this.
But getStorageUpdates is still not the right name for it. The only way
that there'd be any updates to get is if, when you call the function,
someone else takes the lock and makes some updates. Maybe it should be
yieldStorage (or yieldStorageMutex)? In other words, maybe the name should
imply that you're allowing concurrent updates to happen?
I thought that's what getStorageUpdates implied :-).
The getStorageUpdates name seems pretty decent to me when considering it
from the perspective of the caller. The caller is saying that they are OK
with being able to see changes made to the localStorage by other threads.
This cleverly avoids the need to talk about locks, which seems like a good
thing. It is okay for there to be no updates to storage.
-Darin
Re: [whatwg] Storage mutex
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.orgwrote:
First of all, I was wondering why all user prompts are specified as
must release the storage mutex (
http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this
really say must instead of may? IIRC (I couldn't find the original
thread, unfortunately) this was added because of deadlock concerns. It
seems like there might be some UA implementation specific ways this could
deadlock and there is the question of whether we'd want an alert() while
holding the lock to block other execution requiring the lock, but I don't
see why the language should be must. For Chromium, I don't think we'll
need to release the lock for any of these, unless there's some
deadlock scenario I'm missing here.
So if one page grabs the lock and then does an alert(), and another page
in the same domain tries to get the lock, you're going to let the latter
page hang until the user dismisses the alert in the first page?
Yes. And I agree this is sub-optimal, but shouldn't it be left up to the
UAs what to do? I feel like this is somewhat of an odd case to begin with
since alerts lock up most (all?) browsers to a varying degrees even without
using localStorage.
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already pretty
bad), because it willl make applications in visually unrelated tabs and
windows hang.
You can have script connections that span multiple tabs in multiple windows,
so in order to preserve the run-to-completion semantics of JavaScript, it is
important that window.{alert,confirm,prompt,showModalDialog} be modal across
all windows in the browser. This is why those APIs suck rocks, and we
should never create APIs like them again.
Given that different UAs are probably going to have
other scenarios where they have to drop the lock (some of them may even be
purely implementational issues), should we add some way for us to notify
scripts the lock was dropped? A normal event isn't going to be of much
use,
since it'll fire after the scripts execution ends (so the lock would have
been dropped by then anyway). A boolean doesn't seem super useful, but
it's
better than nothing and could help debugging. Maybe fire an exception?
Are
there other options?
A generation counter might be useful.
Ooo, I like that idea. When would the counter increment? It'd be nice if
it didn't increment if the page did something synchronous but no one else
took the lock in the mean time.
Defining no-one else may be difficult. I haven't thought this through, to
be honest, but I think you could update the counter every time the storage
mutex is released and the shared state was modified since the storage mutex
was acquired. Reading the counter would acquire the storage mutex. You'd
basically write
var counter = window.storageMutexGenerationCounter;
... do lots of stuff ...
if (window.storageMutexGenerationCounter != counter) {
// abort, or refresh local state, or something
}
I'm not sure what you'd do if you discovered an undesired lock-drop,
though. If you can't write something sensible instead of abort, or
something, it's not worth doing.
Implementation-wise, the easiest thing to support is a boolean that becomes
true when the lock is release and false when the lock is acquired. Trying
to update a counter based on modifications to the local storage backend
which may be happening on another thread seems like more effort than it is
worth.
But, what would you call this boolean? storageMayHaveBeenUpdated? :-P
I'm struggling to find a good use case for this.
But getStorageUpdates is still not the right name for it. The only way
that there'd be any updates to get is if, when you call the function,
someone else takes the lock and makes some updates. Maybe it should be
yieldStorage (or yieldStorageMutex)? In other words, maybe the name should
imply that you're allowing concurrent updates to happen?
I thought that's what getStorageUpdates implied :-).
The getStorageUpdates name seems pretty decent to me when considering it
from the perspective of the caller. The caller is saying that they are OK
with being able to see changes made to the localStorage by other threads.
This cleverly avoids the need to talk about locks, which seems like a good
thing. It is okay for there to be no updates to storage.
-Darin
Re: [whatwg] Storage mutex
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.org wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already pretty
bad), because it willl make applications in visually unrelated tabs and
windows hang.
You can have script connections that span multiple tabs in multiple
windows, so in order to preserve the run-to-completion semantics of
JavaScript, it is important that
window.{alert,confirm,prompt,showModalDialog} be modal across all windows in
the browser. This is why those APIs suck rocks, and we should never create
APIs like them again.
I don't understand your point here. Are you saying that the current firefox
behavior is not correct, that releasing the storage lock on these events is
not correct, or something else?
Defining no-one else may be difficult. I haven't thought this through, to
be honest, but I think you could update the counter every time the storage
mutex is released and the shared state was modified since the storage mutex
was acquired. Reading the counter would acquire the storage mutex. You'd
basically write
var counter = window.storageMutexGenerationCounter;
... do lots of stuff ...
if (window.storageMutexGenerationCounter != counter) {
// abort, or refresh local state, or something
}
I'm not sure what you'd do if you discovered an undesired lock-drop,
though. If you can't write something sensible instead of abort, or
something, it's not worth doing.
Implementation-wise, the easiest thing to support is a boolean that becomes
true when the lock is release and false when the lock is acquired. Trying
to update a counter based on modifications to the local storage backend
which may be happening on another thread seems like more effort than it is
worth.
Such a boolean could be useful, but I disagree with the assertion that the
implementation is significantly more difficult. I'm pretty sure both would
be trivial in Chromium, for example.
But, what would you call this boolean? storageMayHaveBeenUpdated? :-P
I'm struggling to find a good use case for this.
None of the ones I already listed seemed interesting? If nothing else, I
would think debugability would be a key one. If we're going to do something
halfway magical, we should make it possible for developers to know it
happened, right??
The getStorageUpdates name seems pretty decent to me when considering it
from the perspective of the caller. The caller is saying that they are OK
with being able to see changes made to the localStorage by other threads.
This cleverly avoids the need to talk about locks, which seems like a good
thing. It is okay for there to be no updates to storage.
So the use case I've had in my mind that maybe isn't clear is this:
localStorage.getItem/setItem
navigator.getStorageUpdates()
localStorage.getItem/setItem
In other words, no processing or anything between calls.
If the act of calling getStorageUpdates gives the lock to everyone who's
waiting for it before letting the caller get it again, then I guess I can
buy this argument. I still think yieldStorageMutex (or just about anything
for that matter) would be a much better name, but given that no one's
agreeing with me (on this list, anyhow) I'm just going to drop it.
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, 26 Aug 2009 00:59:31 +0200, Aaron Boodman a...@google.com wrote: On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlowjor...@chromium.org wrote: I still don't understand what use local storage has outside of 'cloud storage'. Even in the extensions use case (which I think is out of scope for this spec), there's no reason you can't sync user preferences and such to the cloud. The use case, though, is local storage, not cloud storage. Requiring cloud storage here kind of defeats the purpose and makes the API a lot harder to use. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] formNoValidate/novalidate/willValidate
2009/8/26 Dean Edwards dean.edwa...@gmail.com: novalidate sticks out like a sore thumb. Can we change it to noValidate. It's only mentioned in the IDL so maybe it's a typo. I agree, it seems a typo. I'm gonna prepare a patch for WebKit to correct that in case specs are modified. -- Bye, Michelangelo
Re: [whatwg] formNoValidate/novalidate/willValidate
On Wed, 26 Aug 2009 06:14:15 +0200, Peter Kasting pkast...@google.com wrote: On Tue, Aug 25, 2009 at 7:56 PM, Dean Edwards dean.edwa...@gmail.comwrote: Looking through the spec I see the following DOM properties: * formNoValidate * novalidate * willValidate There's also formnoValidate actually, and formaction vs formAction on HTMLButtonElement vs HTMLInputElement. Also see http://www.w3.org/Bugs/Public/show_bug.cgi?id=7389 novalidate sticks out like a sore thumb. Can we change it to noValidate. It's only mentioned in the IDL so maybe it's a typo. IIRC when we (my GSoC student and I; he's been working on form validation in WebKit) encountered this recently, we assumed it was a typo, and I used the snazzy little file a bug from directly on this page UI on the spec to note it. PK -- Simon Pieters Opera Software
Re: [whatwg] Adding alpha channel to input type=color
On Wed, Aug 26, 2009 at 2:35 AM, Max Romantschukm...@romantschuk.fi wrote: Victor Vasiliev wrote: I suggest to add a boolean attribute alpha to input type=color (disabled by default). If this attribute is present, the color well allows to set opacity value, and instead of sRGB, sends RGBA. Another question is which format should be used to submit RGBA color. We have rgba(number, number, number, float) used in canvas, but I feel like it's not the best format to be used in submited data. Maybe #rrggbbaa or #aarrggbb? input type=color is specified to define a simple color: http://dev.w3.org/html5/spec/Overview.html#simple-color While alpha information is useful, it's not really a color attribute is it? Using type=color paired with type=range for alpha would serve fairly well in most cases, I believe. How do the people more into design feel about this? I'm mainly a coder myself. Many, though certainly not all, applications that allow color-choosing make alpha a part of the color-chooser dialog. (Some, like GIMP, offer it as a separate choice, similar to your input type=slider suggestion.) CSS has also trained many of us authors that alpha is a component of colors with its rgba() syntax. ~TJ
Re: [whatwg] Adding alpha channel to input type=color
Am Mittwoch, den 26.08.2009, 08:15 -0500 schrieb Tab Atkins Jr.: Many, though certainly not all, applications that allow color-choosing make alpha a part of the color-chooser dialog. (Some, like GIMP, offer it as a separate choice, similar to your input type=slider suggestion.) While having a separate slider thingy seems to be a nice workaround if alpha doesn't make it into the spec, it puts additional burden on part of the web developer and may preclude the use of platform-specific color chooser widgets. Additionally, it isn't clear to me how to extend a color chooser to contain an alpha component later on (say, in HTML6) - if that is possible at all in a simple, backwards-compatible way. CSS has also trained many of us authors that alpha is a component of colors with its rgba() syntax. Interesting. I know of its existence, but almost never use it. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] brief question on 2.4.5 Dates and times
On Tue, Aug 25, 2009 at 9:01 PM, Silvia Pfeiffersilviapfeiff...@gmail.com wrote: Hi, I am trying to use the specification of Dates and times given in section 2.4.5. I was surprised to find that there is a specification of a valid month string, but not of a valid year string or a valid day string. Is that an oversight? Isn't a valid day string just a normal date string? The month string is month-year, after all, not just month. A year string by itself isn't useful in the current spec, as there's nothing that would consume it. time uses a date or datetime, and the various inputs all use times, dates, weeks, or months. ~TJ
Re: [whatwg] Microdata
On Aug 22, 2009, at 5:51 PM, Ian Hickson wrote:
Based on some of the feedback on Microdata recently, e.g.:
http://www.jenitennison.com/blog/node/124
...and a number of e-mails sent to this list and the W3C lists, I am
going
to try some tweaks to the Microdata syntax. Google has kindly
offered to
provide usability testing resources so that we can try a variety of
different syntaxes and see which one is easiest for authors to
understand.
If anyone has any concrete syntax ideas that they would like me to
consider, please let me know. There's a (pretty low) limit to how many
syntaxes we can perform usability tests on, though, so I won't be
able to
test every idea.
Here's an idea I've been mulling around. I think it would simplify the
syntax and semantic model considerably.
Why do we need separate items and item properties? They seem to
confuse people, when something can be both an item and an itemprop at
the same time. They also seem to duplicate a certain amount of
information; items can have types, while itemprops can have names,
but they both seem to serve about the same role, which is to indicate
how to interpret them in the context of page or larger item.
What if we just had item, filling both of the roles? The value of
the item would be either an associative array of the descendent items
(or ones associated using about) if those exists, or the text
content of the item (or URL, depending on the tag) if it has no items
within it.
Here's an example used elsewhere in the thread, marked up as I suggest:
section id=bt200x item=com.example.product
link item=about href=http://example.com/products/bt200x;
h1 item=nameGPS Receiver BT 200X/h1
pRating: #x22C6;#x22C6;#x22C6;#x2729;#x2729; meta
item=rating content=2/p
pRelease Date:
time item=reldate datetime=2009-01-22January 22/time/p
p item=reviewa item=reviewer href=http://ln.hixie.ch/;Ian
/a:
span item=textLots of memory, not much battery, very little
accuracy./span/p
/section
figure item=work
img item=about src=image.jpeg
legend
pcite item=titleMy Pond/cite/p
psmallLicensed under the a item=license
href=http://www.opensource.org/licenses/mit-license.php;MIT
license/a./small
/legend
/figure
pimg subject=bt200x item=image src=bt200x.jpeg alt=.../p
This would translate into the following JSON. Note that this is a
simpler structure than the existing one proposed for microdata; it is
a lot closer to how people generally use JSON natively, rather than
using an extra level of nesting to distinguish types and properties:
// JSON DESCRIPTION OF MARKED UP DATA
// document URL: http://www.example.org/sample/test.html
{
com.example.product: [
{
about: [ http://example.com/products/bt200x; ],
image: [ http://www.example.org/sample/bt200x.jpeg; ]
name: [ GPS Receiver BT 200X ],
reldate: [ 2009-01-22 ],
review: [
{
reviewer: [ http://ln.hixie.ch/; ],
text: [ Lots of memory, not much battery, very little
accuracy. ]
}
],
},
],
work: [
{
about: [ http://www.example.org/sample/image.jpeg; ],
license: [ http://www.opensource.org/licenses/mit-
license.php ]
title: [ My Pond ],
}
]
}
This has the slightly surprising property of making something like this:
section item=fooSome text. a href=somewhereA link/a. Some
more text/section
Result in:
// http://example.org/sample/test
{ foo: [ Some text. A link. Some more text ] }
While simply changing link an item:
section item=fooSome text a item=link href=somewhereA link/
a. Some more text/section
Gives you:
// http://example.org/sample/test
{ foo: [ { link: [ http://example.org/sample/somewhere; ] } ] }
However, I think that people will generally expect item to be used
for its text/URL content only on leaf nodes or nodes without much
nested within them, while they would expect item to return
structured, nested data when the DOM is nested deeply with items
inside it, so I don't think people would be surprised by this behavior
very often.
I haven't yet looked at every use case proposed so far to see how well
this idea works for them, nor have I worked out the API differences
(which should be simpler than the existing API). If there seem to be
no serious problems with this idea, I can write up a more detailed
justification and examples.
-- Brian
Re: [whatwg] Web Storage: apparent contradiction in spec
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 looking for real- world examples. It's a single-user local wiki distributed as an HTML file. It's always had the problem of how to save changes persistently — the basic mechanism is really awkward, requiring you to manually export a new HTML file including the content as embedded JS data. It would be great for it to use local storage (and maybe they've added that since I last looked at it.) Needless to say, some GTD acolytes accumulate tons of crucial personal data in local wikis like this (or VoodooPad) and would be furious if the browser deleted it without their consent. I think there are lots of other use cases for web apps that would use local storage without ever syncing it to the cloud, simply because it's vastly easier to do. I can write such an app and host it on my cheapo personal website without having to worry about user account registration, storage and bandwidth costs for an unknown number of documents, tech support or legal liability if my server loses people's data, privacy requirements, DMCA takedown requests, etc. etc. —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
As an offline cloud-app developer, I've got these three kinds of data:1) Data from the cloud that's cached locally on a best-effort basis, that can be thrown out if we start running out of space. 2) Data from the cloud that the app needs in order to keep functioning at all. 3) Locally created data that may not have been synced to the cloud yet, like emails written on an airplane. Even if the app stops working, this data is still valuable and recovering it is important. Once it is synced, it can usually be downgraded to 'best-effort'. In order for apps to make the best use of the space they have available, especially if space is tight, it'd be great to have an API that indicates how big the app's quota is, and how much space it's taking up now. Then the app code can decide what data to keep and what data to drop, in case it approaches the max. Apps that sync a portion of a larger cloud-based datastore to local disk can also use the local quota info to help decide what to sync. If the UA lets the user adjust the quotas, it'd be nice to expose a quota-max-changed event, so polling won't be necessary. On Tue, Aug 25, 2009 at 3:59 PM, Aaron Boodman a...@google.com wrote: On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlowjor...@chromium.org wrote: I still don't understand what use local storage has outside of 'cloud storage'. Even in the extensions use case (which I think is out of scope for this spec), there's no reason you can't sync user preferences and such to the cloud. The use case, though, is local storage, not cloud storage. Requiring cloud storage here kind of defeats the purpose and makes the API a lot harder to use. - a
Re: [whatwg] Web Storage: apparent contradiction in spec
On 26/08/2009 18:36, Jens Alfke s...@google.com wrote: I think there are lots of other use cases for web apps that would use local storage without ever syncing it to the cloud, simply because it's vastly easier to do. I can write such an app and host it on my cheapo personal website without having to worry about user account registration, storage and bandwidth costs for an unknown number of documents, tech support or legal liability if my server loses people's data, privacy requirements, DMCA takedown requests, etc. etc. On the other hand, look at it from a user's point of view - where is the data on disk? How do I back it up? The browser's local storage is very opaque and hidden to the user so it's not a safe place to save important data since it's unlikely to be thought of when it comes to backing up. We do clearly have two types of local storage data though - one set is a local cache and should be garbage collected automatically if I don't use the site for a while or if space is tight. As a user, I really want that functionality - otherwise I have to either disable local storage and have permission dialogs popping up all the time to make exceptions, or have an ever growing database of rubbish on my drive. On the other hand, there will be a handful of sites where I explicitly decide that the data I create is important. The natural tendency would be to select a location on my disk where the local storage for that webapp would be saved. Then it becomes a visible, manageable file on my disk. Devices like the iPhone where there's no file management, would probably just have a flag to say whether it is permanent or not. I'm not sure how this fits into what the spec says of course, but from a user's perspective, I don't want to lose important data, but I also don't want to keep every bit of local storage forever. The spec really needs to allow both, but have a flag to tell the application which mode is being used. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 628 200 182 x481 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Storage mutex
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.org wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already pretty
bad), because it willl make applications in visually unrelated tabs and
windows hang.
You can have script connections that span multiple tabs in multiple
windows, so in order to preserve the run-to-completion semantics of
JavaScript, it is important that
window.{alert,confirm,prompt,showModalDialog} be modal across all windows in
the browser. This is why those APIs suck rocks, and we should never create
APIs like them again.
I don't understand your point here. Are you saying that the current
firefox behavior is not correct, that releasing the storage lock on these
events is not correct, or something else?
I meant that the current Firefox behavior is technically incorrect. No one
likes app modal dialogs, but how else can you guarantee run-to-completion
semantics? How else do you prevent other scripts from modifying your state
while you are stuck calling into window.alert().
Defining no-one else may be difficult. I haven't thought this through, to
be honest, but I think you could update the counter every time the storage
mutex is released and the shared state was modified since the storage mutex
was acquired. Reading the counter would acquire the storage mutex. You'd
basically write
var counter = window.storageMutexGenerationCounter;
... do lots of stuff ...
if (window.storageMutexGenerationCounter != counter) {
// abort, or refresh local state, or something
}
I'm not sure what you'd do if you discovered an undesired lock-drop,
though. If you can't write something sensible instead of abort, or
something, it's not worth doing.
Implementation-wise, the easiest thing to support is a boolean that
becomes true when the lock is release and false when the lock is acquired.
Trying to update a counter based on modifications to the local storage
backend which may be happening on another thread seems like more effort than
it is worth.
Such a boolean could be useful, but I disagree with the assertion that the
implementation is significantly more difficult. I'm pretty sure both would
be trivial in Chromium, for example.
incrementing a counter on each modification to the database would involve
some broadcasting of notifications to each renderer, or we'd need to store
the counter in shared memory. either seems unfortunate given the debugging
use case.
if we only record the fact that getStorageUpdates (or equivalent) was
called, then it is just a local boolean in the renderer process. that seems
substantially simpler to implement without performance penalty.
But, what would you call this boolean? storageMayHaveBeenUpdated? :-P
I'm struggling to find a good use case for this.
None of the ones I already listed seemed interesting? If nothing else, I
would think debugability would be a key one. If we're going to do something
halfway magical, we should make it possible for developers to know it
happened, right??
The getStorageUpdates name seems pretty decent to me when considering it
from the perspective of the caller. The caller is saying that they are OK
with being able to see changes made to the localStorage by other threads.
This cleverly avoids the need to talk about locks, which seems like a good
thing. It is okay for there to be no updates to storage.
So the use case I've had in my mind that maybe isn't clear is this:
localStorage.getItem/setItem
navigator.getStorageUpdates()
localStorage.getItem/setItem
In other words, no processing or anything between calls.
If the act of calling getStorageUpdates gives the lock to everyone who's
waiting for it before letting the caller get it again, then I guess I can
buy this argument.
right, this ^^^ is what i meant.
-darin
[whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.orgwrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already pretty
bad), because it willl make applications in visually unrelated tabs and
windows hang.
You can have script connections that span multiple tabs in multiple
windows, so in order to preserve the run-to-completion semantics of
JavaScript, it is important that
window.{alert,confirm,prompt,showModalDialog} be modal across all windows in
the browser. This is why those APIs suck rocks, and we should never create
APIs like them again.
I don't understand your point here. Are you saying that the current
firefox behavior is not correct, that releasing the storage lock on these
events is not correct, or something else?
I meant that the current Firefox behavior is technically incorrect. No one
likes app modal dialogs, but how else can you guarantee run-to-completion
semantics? How else do you prevent other scripts from modifying your state
while you are stuck calling into window.alert().
I don't know much about this issue, but it seems like something that should
either be fixed in Firefox (and other browsers?) or changed in the spec.
I'm interested to hear if others have thoughts on it.
Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.orgwrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already pretty
bad), because it willl make applications in visually unrelated tabs and
windows hang.
You can have script connections that span multiple tabs in multiple
windows, so in order to preserve the run-to-completion semantics of
JavaScript, it is important that
window.{alert,confirm,prompt,showModalDialog} be modal across all windows
in
the browser. This is why those APIs suck rocks, and we should never create
APIs like them again.
I don't understand your point here. Are you saying that the current
firefox behavior is not correct, that releasing the storage lock on these
events is not correct, or something else?
I meant that the current Firefox behavior is technically incorrect. No
one likes app modal dialogs, but how else can you guarantee
run-to-completion semantics? How else do you prevent other scripts from
modifying your state while you are stuck calling into window.alert().
I don't know much about this issue, but it seems like something that should
either be fixed in Firefox (and other browsers?) or changed in the spec.
I'm interested to hear if others have thoughts on it.
Chrome and Safari both implement app-modal alerts. Firefox and IE implement
window modal, which is clearly buggy, but of course the world hasn't
imploded. I haven't tested Opera.
Personally, I would like to change Chrome to not put up app modal alerts. I
think it is bad UI, but I'm not sure how to do so without also breaking the
contract that JavaScript execution appear single threaded.
-Darin
Re: [whatwg] Storage mutex
On Wed, Aug 26, 2009 at 12:49 AM, Darin Fisher da...@google.com wrote: On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote: But getStorageUpdates is still not the right name for it. The only way that there'd be any updates to get is if, when you call the function, someone else takes the lock and makes some updates. Maybe it should be yieldStorage (or yieldStorageMutex)? In other words, maybe the name should imply that you're allowing concurrent updates to happen? I thought that's what getStorageUpdates implied :-). The getStorageUpdates name seems pretty decent to me when considering it from the perspective of the caller. The caller is saying that they are OK with being able to see changes made to the localStorage by other threads. This cleverly avoids the need to talk about locks, which seems like a good thing. It is okay for there to be no updates to storage. -Darin What about allowStorageUpdates? -Darin
Re: [whatwg] HTML5 History Management
Ian Hickson wrote: On Sun, 16 Aug 2009, Mike Wilson wrote: Ian Hickson wrote: I don't think we should encourage cases where the same URL can correspond to multiple states, which this would encourage. This statement confuses me as the whole point of pushState seems to be to store unique state in addition to the URL. If the URL can be used to infer the state anyway, then what's the point of storing it in the history entry? It's mostly about being able to track extra state that isn't important to the user. For example, if you have an application with many boxes, and two states, one with one box open, and another with another box open, and the boxes are randomly dotted around but move when a box is opened or closed, and you then hit back-forward-back-forward, you would want the same two boxes to move in the same way each time. However, if you just jump straight to the URI representing those two states, the exact position of the boxes doesn't matter, and might differ each time. The state object is for keeping track of that kind of thing (the position of the boxes). It seems we do indeed agree that the state object is for storing state that could differ for multiple history entries for the same URL, and what you are actually saying is that you think this feature should not be used for important state. I'm fine as long the former is true, and you are free to have an opinion about the latter. Though, when taking a more thorough look at what is spec:ed, it seems these use cases are indeed not supported, due to state update limitations and how events are ordered. I've tried to fix this by making popstate more synchronous. I still don't think this fixes my issues. I've described most of these in the thread Proposed changes to the History API so I'll wait until you reply to that before commenting further here. Best regards Mike
[whatwg] Storage mutex and cookies can lead to browser deadlock
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 storage, whereby a worker thread can deadlock the browser. This is because access to cookies, by workers or the browser itself, is also subject to that global mutex. Consider these steps: 1. A worker thread accesses document.cookie. This causes it to acquire the mutex (sec. 3.1.3). 2. The thread now performs some long-lasting operation without exiting. In the simplest case it just goes into an infinite loop. 3. Meanwhile, the user loads a new web page in the browser. 4. The resulting HTTP response contains a Cookie: header. The spec requires that the browser's loader temporarily acquire the mutex while updating the cookie (sec. 2.6, item 4). 5. The page-load blocks indefinitely because the worker thread still has the mutex and never lets go of it. The result is that the browser becomes incapable of loading any web pages that use cookies. Assuming the worker thread never exits, the only way to recover from this is to quit the browser. A worker thread like this could very easily be created by a malicious website, resulting in a DoS attack on the browser. And of course, a merely poorly-written script could create the same effect without intending to. I honestly can't think of any safe way of tweaking the semantics of the existing 'document.cookie' API to make it transactional. :( Has anyone implemented this portion of the spec yet? —Jens
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
My recollection is that we prohibit worker access to cookies for exactly this reason (WorkerGlobalScope does not expose a cookies attribute). -atw On Wed, Aug 26, 2009 at 2:05 PM, Jens Alfke s...@google.com wrote: 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 storage, whereby a worker thread can deadlock the browser. This is because access to cookies, by workers or the browser itself, is also subject to that global mutex. Consider these steps: 1. A worker thread accesses document.cookie. This causes it to acquire the mutex (sec. 3.1.3). 2. The thread now performs some long-lasting operation without exiting. In the simplest case it just goes into an infinite loop. 3. Meanwhile, the user loads a new web page in the browser. 4. The resulting HTTP response contains a Cookie: header. The spec requires that the browser's loader temporarily acquire the mutex while updating the cookie (sec. 2.6, item 4). 5. The page-load blocks indefinitely because the worker thread still has the mutex and never lets go of it. The result is that the browser becomes incapable of loading any web pages that use cookies. Assuming the worker thread never exits, the only way to recover from this is to quit the browser. A worker thread like this could very easily be created by a malicious website, resulting in a DoS attack on the browser. And of course, a merely poorly-written script could create the same effect without intending to. I honestly can't think of any safe way of tweaking the semantics of the existing 'document.cookie' API to make it transactional. :( Has anyone implemented this portion of the spec yet? —Jens
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
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, Document objects, etc) are not available to workers in this version of this specification. and there's no defined way to access cookies except through Document. Crisis averted. (If the spec does get modified to allow local-storage access from worker threads, though, this same problem will arise, since they use the same lock.) —Jens
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
We discussed this in more detail here: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg13799.html At the time, I suggested not protecting cookies with a mutex (allow asynchronous access - the current behavior on IE and Chrome), which made the monocles pop out of everyone's eyes :) -atw On Wed, Aug 26, 2009 at 2:21 PM, Jens Alfke s...@google.com wrote: 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, Document objects, etc) are not available to workers in this version of this specification. and there's no defined way to access cookies except through Document. Crisis averted. (If the spec does get modified to allow local-storage access from worker threads, though, this same problem will arise, since they use the same lock.) —Jens
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
Is there any data (or any way to collect the data) on how much of the web IE and Chrome's current behavior has broken? Given that there hasn't been panic in the streets, I'm assuming approximately 0%? Given that web developers have never had any guarantees for cookie access/setting in terms of network communications and given that (it sounds like) it won't break the web, maybe we should ditch the idea of locking during cookie access/setting? On Wed, Aug 26, 2009 at 2:42 PM, Drew Wilson atwil...@google.com wrote: We discussed this in more detail here: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg13799.html At the time, I suggested not protecting cookies with a mutex (allow asynchronous access - the current behavior on IE and Chrome), which made the monocles pop out of everyone's eyes :) -atw On Wed, Aug 26, 2009 at 2:21 PM, Jens Alfke s...@google.com wrote: 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, Document objects, etc) are not available to workers in this version of this specification. and there's no defined way to access cookies except through Document. Crisis averted. (If the spec does get modified to allow local-storage access from worker threads, though, this same problem will arise, since they use the same lock.) —Jens
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow jor...@chromium.org wrote: Is there any data (or any way to collect the data) on how much of the web IE and Chrome's current behavior has broken? Given that there hasn't been panic in the streets, I'm assuming approximately 0%? We previously had a lengthy discussion about this. If a site has a cookie race that causes a problem in IE/Chrome one in every 10,000 page loads, are you comfortable with that? I'm much more comfortable with that than the cost of a global mutex that all cookies and LocalStorage share. There are other ways to come about this problem (like developer tools). I'm pretty sure Chromium has no intention of implementing a global storage mutex and putting all cookie access under it. Has anyone heard anything (either way) from Microsoft? Are there any browsers moving to a multi-event-loop (be it multi-threaded or multi-process) based model that intend to implement this? If not, then it would seem like the spec is not grounded in reality.
[whatwg] Note on the DETAILS element
The text for details begins with a definition: The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines. But then has this note immediately afterwards: The point of hgroup is to mask an h2 element (that acts as a secondary title) from the outline algorithm. As far as I can tell, this is incorrect. The point of an hgroup is actually to mask *all but one* heading element from the outline algorithm. The note *does* apply to the examples provided: hgroup h1Dr. Strangelove/h1 h2Or: How I Learned to Stop Worrying and Love the Bomb/h2 /hgroup ...but wouldn't be true in this case: hgroup h3Dr. Strangelove/h3 h4Or: How I Learned to Stop Worrying and Love the Bomb/h4 /hgroup In this case, the hgroup element is masking an h4 element (that acts as a secondary title) from the outline algorithm. Even in cases where the hgroup *is* masking an h2, the note would still be incorrect because more heading elements can be hidden from the outline algorithm. e.g.: hgroup h1Dr. Strangelove/h1 h2Or: How I Learned to Stop Worrying and Love the Bomb/h2 h3By Stanley Kubrick/h3 /hgroup The note would make sense if it were moved down to the examples and prefaced with In this case... -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 4:01 PM, Linus Upson li...@google.com 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 your disk by downloading them from the internet, copying from a network drive, from a floppy, your camera, etc. You put them on your disk and you are responsible for removing them to reclaim space. There are apps that create files in hidden places such as: C:\Documents and Settings\linus\Local Settings\Application Data\Google\Chrome\User Data If those apps do not manage their space carefully, users get annoyed. If such an app filled the user's disk they would have no idea what consumed the space or how to reclaim it. They didn't put the files there. How are they supposed to know to remove them? Most users have no idea that Local Settings exists (it is hidden), much less how to correctly manage any files they find. This seems like an argument for ensuring web apps have as much ability to take reasonable steps to control their space usage as local apps do, not an argument that the UA should be able to discard those files. After all, you are not arguing that Windows should be able to throw away those non-user-visible files in Local Storage. Without automatic space management the local storage consumed will grow without bound. I'm concerned that even without an intentional DOS attack users are going to be unhappy about their shrinking disks and not know what to do about it. The problem is worse on phones. I don't think anyone is suggesting UAs should not have the ability to control the total space usage, e.g. by presetting per-app and global quotas. That's not the same as saying that the UA can throw away data after the fact. Things get worse still if a griefer wants to make a point about the importance of keeping web browsers logically stateless. Here's how such an attack could be carried out: 2a. Acquire a bunch of unrelated domains from a bunch of registrars using stolen credit cards. Skip this step if UAs don't group subdomains under the same storage quota. For extra credit pick names that are similar to legitimate sites that use local storage. 2b. Start up some web hosting accounts. Host your attack code here. If they aren't free, use stolen credit cards. 2c. Buy ads from a network that subsyndicates from a network that subsyndicates from a major ad network that allows 3rd party ad serving. There are lots to choose from. No money? Stolen credit cards. Serve the ads from your previously acquired hosting accounts. 2d. Giggle. The user will be faced with the choice of writing off the space, deleting everything including their precious data, or carefully picking though tens of thousands of entries to find the few domains that hold precious content. User gets really unhappy if the attack managed to fill the disk. I'm not sure why this is more compelling for a griefer than the existing attack (along similar lines) they can already make against the cookie store to blow away 100% of the user's cookies, and keep doing it, such that the user can never log in anywhere. In fact, to some degree that's a testimony that treating things like cookies doesn't mean users will be free from griefing. In practice I don't foresee either of these happening unless doing so allows attackers monetary gain. Chrome's Incognito mode creates a temporary, in-memory profile. Local storage operations will work, but nothing will be saved after the Incognito window is closed. Safari takes a different approach and causes local storage operations to fail when in Private Browsing mode. Some sites won't work in Private Browsing. I don't recall what Firefox or IE do. Pick your poison. This is a problem that has to be solved regardless, and it doesn't seem like a bad one. If the purpose of section 6.1 is to state that UAs must give users the ability to see and clean up their Local Storage data (which seems to me like a good idea but outside the scope of what HTML5 should be specifying), then users have the ability to manually delete this data anyway, and live with the consequences. Chrome's behavior is akin to a user manually clearing his Local Storage data, and Safari's is akin to an app hitting its quota. Apps have to be able to deal with both anyway, perhaps with a (possibly large) reduction in functionality. While that may sound like an argument for your position (since I am saying that apps need to deal with disappearing Local Storage data), the critical difference is that the user is in control of this, either by cleaning up the data manually or by electing to use a private browsing mode. Thus I don't think it justifies some UA behavior when the user is _not_ in explicit control. If the spec requires UAs to maintain local storage as 'precious' it will be the first such
Re: [whatwg] Web Storage: apparent contradiction in spec
At a minimum the HTML 5 spec should be silent on how user agents implement local storage policies. +1 linus The sort of 'policies' being discussed are feeling 'out-of-scope' for the HTML5 spec. The practical realities are that eviction needs to be there in some form w/o an explicit user 'installation' step. Something that could be appropriately specified is the grain size of local data eviction... * Can an individual key,value pair for an origin be removed from local storage while leaving other local data in place? * Can an individual Database be deleted for an origin while leaving other local data in place? * Can an individual Manifest be deleted for an origin while leaving other local data in place? * Or should an origin's data be subject to all-or-none eviction. I would prefer to see the spec clarify questions along those lines. That would be useful. A mandate from on high that says 'shall store forever and ever' will be promptly ignored because its impossible to make that guarantee. On Wed, Aug 26, 2009 at 4:01 PM, Linus Upson li...@google.com wrote: Not convinced. :) 1. Analogies 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 your disk by downloading them from the internet, copying from a network drive, from a floppy, your camera, etc. You put them on your disk and you are responsible for removing them to reclaim space. There are apps that create files in hidden places such as: C:\Documents and Settings\linus\Local Settings\Application Data\Google\Chrome\User Data If those apps do not manage their space carefully, users get annoyed. If such an app filled the user's disk they would have no idea what consumed the space or how to reclaim it. They didn't put the files there. How are they supposed to know to remove them? Most users have no idea that Local Settings exists (it is hidden), much less how to correctly manage any files they find. A better analogy would be, What if watching TV caused 0-5MB size files to silently be created from time to time in a hidden folder on your computer, and when your disk filled up both your TV and computer stopped working? Lengthy discussion on cleaning up hidden resources (persistent background content) here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021421.html 2. Attack Without automatic space management the local storage consumed will grow without bound. I'm concerned that even without an intentional DOS attack users are going to be unhappy about their shrinking disks and not know what to do about it. The problem is worse on phones. Things get worse still if a griefer wants to make a point about the importance of keeping web browsers logically stateless. Here's how such an attack could be carried out: 2a. Acquire a bunch of unrelated domains from a bunch of registrars using stolen credit cards. Skip this step if UAs don't group subdomains under the same storage quota. For extra credit pick names that are similar to legitimate sites that use local storage. 2b. Start up some web hosting accounts. Host your attack code here. If they aren't free, use stolen credit cards. 2c. Buy ads from a network that subsyndicates from a network that subsyndicates from a major ad network that allows 3rd party ad serving. There are lots to choose from. No money? Stolen credit cards. Serve the ads from your previously acquired hosting accounts. 2d. Giggle. The user will be faced with the choice of writing off the space, deleting everything including their precious data, or carefully picking though tens of thousands of entries to find the few domains that hold precious content. User gets really unhappy if the attack managed to fill the disk. 3. Ingcognito / Private Browsing Chrome's Incognito mode creates a temporary, in-memory profile. Local storage operations will work, but nothing will be saved after the Incognito window is closed. Safari takes a different approach and causes local storage operations to fail when in Private Browsing mode. Some sites won't work in Private Browsing. I don't recall what Firefox or IE do. Pick your poison. Lengthy discussion here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-April/019238.html 4. Cache Eviction Algorithms At a minimum the HTML 5 spec should be silent on how user agents implement local storage policies. I would prefer the spec to make it clear that local storage is a cache, domains can use up to 5MB of space without interrupting the user, and that UAs were free to implement varying cache eviction algorithms. Some browsers may provide interface to allow users to specify precious local storage, some may not. Eviction policies for installed extensions may be different than those for web pages. Quotas for extensions may be
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman micha...@google.comwrote: A mandate from on high that says 'shall store forever and ever' will be promptly ignored because its impossible to make that guarantee. That's not the proposed mandate. The proposed mandate is thou shalt not discard successfully-written data without explicit user action, which seems implementable to me. Note that this doesn't make claims like the hard drive will not fail, and it doesn't claim that the UA is required to allow the app to write whatever data it wants in the first place. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
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 your disk by downloading them from the internet, copying from a network drive, from a floppy, your camera, etc. A web app would also be pretty likely to put stuff in local storage as a result of explicit user action. The use cases seem pretty similar. Also, you're not counting files that you create locally. After all, files have to come from somewhere :) Those are the most precious since they're yours and they may not live anywhere else if you haven't backed them up or copied them elsewhere. There's no reason web-apps can't create the same kind of content, and it would look very similar to a user: I go to the word processor [website], click New Document, type some stuff, and click Save. Even if the save process involves migrating the local data up to the cloud, that transition is not instantaneous: it can take arbitrarily large amounts of time if there are network/server problems or the user is offline. During that time, the local storage represents the only copy of the data. There is therefore a serious race condition where, if the browser decides to purge local data before the app has uploaded it, the data is gone forever. A better analogy would be, What if watching TV caused 0-5MB size files to silently be created from time to time in a hidden folder on your computer, and when your disk filled up both your TV and computer stopped working? This is a cache — that isn't the kind of usage I'm concerned about. Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't. (For example, the Mac OS has separate 'Caches' and 'Application Support' subfolders of ~/Library/.) First, this is what quotas are for. The TV web-app would have a limited quota of space to cache stuff. Second, the browser should definitely help you delete stuff like this if disk space does get low; I'm just saying it shouldn't delete it silently or as part of some misleading command like Empty Cache or Delete Cookies. At a minimum the HTML 5 spec should be silent on how user agents implement local storage policies. I would prefer the spec to make it clear that local storage is a cache, domains can use up to 5MB of space without interrupting the user, and that UAs were free to implement varying cache eviction algorithms. That will have the effect of making an interesting category of new applications fail, with user data loss, on some browsers. That sounds like a really bad idea to me. To repeat what I said up above: Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't. —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
Ok... I overstated things ;) 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. I'm assuming that UA will have out-of-band mechanisms to 'bless' certain sites which should not be subject to automated eviction. If push comes to shove, the system could suggest cleaning up one of these 'blessed' sites if inactivity for an extended period was noticed. But for the overwhelming number of sites in a users browsing history, its a different matter. If the storage APIs are just available for use, no questions asked making the storage just go away, no questions asked, is symmetrical. Blessing involves asking questions... making it go away does too. On Wed, Aug 26, 2009 at 4:35 PM, Peter Kasting pkast...@google.com wrote: On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman micha...@google.comwrote: A mandate from on high that says 'shall store forever and ever' will be promptly ignored because its impossible to make that guarantee. That's not the proposed mandate. The proposed mandate is thou shalt not discard successfully-written data without explicit user action, which seems implementable to me. Note that this doesn't make claims like the hard drive will not fail, and it doesn't claim that the UA is required to allow the app to write whatever data it wants in the first place. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't.* * *What if instead of the storage APIs providing a way to distinguish things, UA's provide a way for users to indicate which applications are important, and UA's provide a way for applications guide a user towards making that indication.* *Seems like permissioning, blessing, could happen out-of-band of the existing storage APIs.* * * On Wed, Aug 26, 2009 at 4:51 PM, Jens Alfke s...@google.com wrote: 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 your disk by downloading them from the internet, copying from a network drive, from a floppy, your camera, etc. A web app would also be pretty likely to put stuff in local storage as a result of explicit user action. The use cases seem pretty similar. Also, you're not counting files that you *create* locally. After all, files have to come from somewhere :) Those are the most precious since they're yours and they may not live anywhere else if you haven't backed them up or copied them elsewhere. There's no reason web-apps can't create the same kind of content, and it would look very similar to a user: I go to the word processor [website], click New Document, type some stuff, and click Save. Even if the save process involves migrating the local data up to the cloud, that transition is not instantaneous: it can take arbitrarily large amounts of time if there are network/server problems or the user is offline. During that time, *the local storage represents the only copy of the data*. There is therefore a serious race condition where, if the browser decides to purge local data before the app has uploaded it, the data is gone forever. A better analogy would be, What if watching TV caused 0-5MB size files to silently be created from time to time in a hidden folder on your computer, and when your disk filled up both your TV and computer stopped working? This is a cache — that isn't the kind of usage I'm concerned about. Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't. (For example, the Mac OS has separate 'Caches' and 'Application Support' subfolders of ~/Library/.) First, this is what quotas are for. The TV web-app would have a limited quota of space to cache stuff. Second, the browser should definitely help you delete stuff like this if disk space does get low; I'm just saying it shouldn't delete it silently or as part of some misleading command like Empty Cache or Delete Cookies. At a minimum the HTML 5 spec should be silent on how user agents implement local storage policies. I would prefer the spec to make it clear that local storage is a cache, domains can use up to 5MB of space without interrupting the user, and that UAs were free to implement varying cache eviction algorithms. That will have the effect of making an interesting category of new applications fail, with user data loss, on some browsers. That sounds like a really bad idea to me. To repeat what I said up above: *Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't.* —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
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 already do this? If I do something like enabling local draft storage in WordPress, I get a prompt asking me if I want to allow myblog.com to store some local data on my disk, and I click OK because after all that's what I asked the site to do. I'm assuming that UA will have out-of-band mechanisms to 'bless' certain sites which should not be subject to automated eviction. If this is out-of-spec and browser-dependent, there won't be a good way for an app to request that blessing; it'll be something the user has to know to do, otherwise their data can get lost. That seems dangerous. In most systems user data loss is just about the worst-case scenario of what could go wrong, and you try to prevent it at all costs. My suggestion to have separate 'important' and 'cache' local storage areas would provide such a mechanism in a standard way. The first time an app tried to put stuff in the 'important' area, you'd be asked for approval. And 'important' stores wouldn't be deleted without your consent. —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Aug 27, 2009 at 1:55 AM, Michael Nordmanmicha...@google.com wrote: Ok... I overstated things ;) 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. As far as I know, cookies work the same way as the proposed local storage policy: once a cookie is created, the browser won't delete it when space becomes a problem. The site controls the expiration date of the cookie, and it can fill up the entire drive with cookies if it wants to do so. This is all without user interaction. I don't think this has ever been a problem. -- Remco
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 5:08 PM, Remco remc...@gmail.com wrote: As far as I know, cookies work the same way as the proposed local storage policy: once a cookie is created, the browser won't delete it when space becomes a problem. The site controls the expiration date of the cookie, and it can fill up the entire drive with cookies if it wants to do so. This is all without user interaction. I don't think this has ever been a problem. This is not at all how cookies work. All UAs have various limits (e.g. a per-host and global limit) and purge cookies silently when those limits are reached. It is exactly this model which Linus is proposing for Local Storage. Cookies disappearing causes problems like users not being logged in when they return to a site, sites forgetting user preferences, and (importantly to publishers) ad tracking not working well. All of these are reasons why various sites now use Flash to store cookies instead/in addition. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
I started writing a detailed rebuttal to Linus's reply, but by the time I was finished, many others had already delivered more targetted replies. So I'll cut the rebuttal format and make a few specific points. - Many apps act as a shoebox for managing specific types of data, and users are used to using these apps to manage that data directly. See iTunes, Windows Media Player, iPhoto, and desktop mail clients as examples. This trend is growing, not waning. Browsers are already a shoebox for history, bookmarks, and other types of data. Claiming that this data is hidden from users who are used to handling obscure file management scenarios and therefore we shouldn't fully respect it is trying to fit in with the past, not trying to make the future better. - No one is suggesting that UAs not have whatever freedom they want in deciding *what* or *how much* to store. We're only suggesting that once the UA has committed to storing it, it *not* be allowed to arbitrarily purge it. - One use of LocalStorage is as a cache for data that is transient and non-critical in nature, or that will live on a server. But another, just-as-valid use of LocalStorage is for persistent, predictable storage in the client UA that will never rely on anything in the cloud. - And on that note, if developers don't have faith that data in LocalStorage is actually persistent and safe, they won't use it. I've given talks on this point 4 times in the last year, and I am stating this as a fact, based on real-world feedback from actual, real- world web developers: If LocalStorage is defined in the standard to be a purgable cache, developers will continue to use what they're already comfortable with, which is Flash's LocalStorage. When a developer is willing to instantiate a plug-in just to reliably store simple nuggets of data - like user preferences and settings - because they don't trust the browser, then I think we've failed in moving the web forward. I truly hope we can sway the LocalStorage is a cache crowd. But if we can't, then I would have to suggest something crazy - that we add a third Storage object. (Note that Jens - from Google - has already loosely suggested this) So we'd have something like: -SessionStorage - That fills the per browsing context role and whose optionally transient nature is already well spec'ed -CachedStorage - That fills Google's interpretation of the LocalStorage role in that it's global, and will probably be around on the disk in the future, maybe -FileStorage - That fills Apple's interpretation of the LocalStorage role in that it's global, and is as sacred as a file on the disk (or a song in your media library, or a photo in your photo library, or a bookmark, or...) The names are just suggestions at this point. ~Brady
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 5:08 PM, Remco remc...@gmail.com wrote: On Thu, Aug 27, 2009 at 1:55 AM, Michael Nordmanmicha...@google.com wrote: Ok... I overstated things ;) 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. As far as I know, cookies work the same way as the proposed local storage policy: once a cookie is created, the browser won't delete it when space becomes a problem. The site controls the expiration date of the cookie, and it can fill up the entire drive with cookies if it wants to do so. This is all without user interaction. I don't think this has ever been a problem. a. cookies are compartively small... size constraints built in b. UA's actually do evict cookies if need be (hasn't ever been a problem) c. they have expriration dates, these new pieces of info don't -- Remco
Re: [whatwg] Web Storage: apparent contradiction in spec
My suggestion to have separate 'important' and 'cache' local storage areas would provide such a mechanism in a standard way. The first time an app tried to put stuff in the 'important' area, you'd be asked for approval. And 'important' stores wouldn't be deleted without your consent. I think you just described a way to 'bless' things. On Wed, Aug 26, 2009 at 5:06 PM, Jens Alfke s...@google.com wrote: 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 already do this? If I do something like enabling local draft storage in WordPress, I get a prompt asking me if I want to allow myblog.com to store some local data on my disk, and I click OK because after all that's what I asked the site to do. Yes, but we hate those prompts, don't you? I'm assuming that UA will have out-of-band mechanisms to 'bless' certain sites which should not be subject to automated eviction. If this is out-of-spec and browser-dependent, there won't be a good way for an app to request that blessing; it'll be something the user has to know to do, otherwise their data can get lost. That seems dangerous. In most systems user data loss is just about the worst-case scenario of what could go wrong, and you try to prevent it at all costs. I'd love it if HTML5 took on a standard means of 'blessing' things. Thus far every time we come even close to the notion of 'installing' something... it doesn't go well in this forum. My suggestion to have separate 'important' and 'cache' local storage areas would provide such a mechanism in a standard way. The first time an app tried to put stuff in the 'important' area, you'd be asked for approval. And 'important' stores wouldn't be deleted without your consent. Interesting... I think you just described a way to 'bless' things by alluding to 'important' repositories and trying to put something in them. There are probably other ways to express this too that wouldn't involve altering the storage APIs... i'd prefer to pursue things in a more modular fashion... jmho. —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 4:55 PM, Michael Nordman micha...@google.comwrote: 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. I hate prompts as much as you. Flash uses a model where a site can silently store small amounts of data with no prompts. Because devices have wildly different storage amounts, one could imagine a UA on a desktop machine allowing a site to store, say, 2 MB without prompting, while on a phone the site might only get 20 KB, or maybe none at all. This would mean users would be prompted sooner or more often on a phone, which seems like a reasonable outcome to me given that a phone may have so little storage that serious use of Local Storage may be difficult to impossible anyway. In this world, the hard quotas I suggested become soft quotas which result in some kind of user elevation. A UA could elect not to elevate and just deny the additional space if its authors felt that prompts were evil :) I'm assuming that UA will have out-of-band mechanisms to 'bless' certain sites which should not be subject to automated eviction. If push comes to shove, the system could suggest cleaning up one of these 'blessed' sites if inactivity for an extended period was noticed. But for the overwhelming number of sites in a users browsing history, its a different matter. If the storage APIs are just available for use, no questions asked making the storage just go away, no questions asked, is symmetrical. Blessing involves asking questions... making it go away does too. If we suggest that the user be prompted before anything be written persistently, there are a couple bad outcomes (note that these are problems with Gears today): * The user is asked to make a choice _before_ using the app's functionality, at which point he is ill-prepared to decide how much he likes the app or what it should be able to do * The app author is less-likely to bother to use Local Storage since prompts drive users away, and just uses Flash I think the overall UX from requiring blessing on all persistent data (as opposed to on large data sets) is poorer. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Aug 27, 2009 at 2:26 AM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 26, 2009 at 4:55 PM, Michael Nordman micha...@google.com 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. I hate prompts as much as you. Flash uses a model where a site can silently store small amounts of data with no prompts. Because devices have wildly different storage amounts, one could imagine a UA on a desktop machine allowing a site to store, say, 2 MB without prompting, while on a phone the site might only get 20 KB, or maybe none at all. This would mean users would be prompted sooner or more often on a phone, which seems like a reasonable outcome to me given that a phone may have so little storage that serious use of Local Storage may be difficult to impossible anyway. In this world, the hard quotas I suggested become soft quotas which result in some kind of user elevation. A UA could elect not to elevate and just deny the additional space if its authors felt that prompts were evil :) This makes me think about applications that need to store huge amounts of data in order to work. Imagine that Quake Live is ported to WebGL and uses Local Storage so it can work without any plugin. The app will want to store some 500MB of game data. If local storage were to work like a cache, then everything else would likely get purged each time you play the game. -- Remco
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote: I started writing a detailed rebuttal to Linus's reply, but by the time I was finished, many others had already delivered more targetted replies. So I'll cut the rebuttal format and make a few specific points. - Many apps act as a shoebox for managing specific types of data, and users are used to using these apps to manage that data directly. See iTunes, Windows Media Player, iPhoto, and desktop mail clients as examples. This trend is growing, not waning. Browsers are already a shoebox for history, bookmarks, and other types of data. Claiming that this data is hidden from users who are used to handling obscure file management scenarios and therefore we shouldn't fully respect it is trying to fit in with the past, not trying to make the future better. - No one is suggesting that UAs not have whatever freedom they want in deciding *what* or *how much* to store. We're only suggesting that once the UA has committed to storing it, it *not* be allowed to arbitrarily purge it. - One use of LocalStorage is as a cache for data that is transient and non-critical in nature, or that will live on a server. But another, just-as-valid use of LocalStorage is for persistent, predictable storage in the client UA that will never rely on anything in the cloud. - And on that note, if developers don't have faith that data in LocalStorage is actually persistent and safe, they won't use it. I've given talks on this point 4 times in the last year, and I am stating this as a fact, based on real-world feedback from actual, real-world web developers: If LocalStorage is defined in the standard to be a purgable cache, developers will continue to use what they're already comfortable with, which is Flash's LocalStorage. When a developer is willing to instantiate a plug-in just to reliably store simple nuggets of data - like user preferences and settings - because they don't trust the browser, then I think we've failed in moving the web forward. I truly hope we can sway the LocalStorage is a cache crowd. But if we can't, then I would have to suggest something crazy - that we add a third Storage object. (Note that Jens - from Google - has already loosely suggested this) So we'd have something like: -SessionStorage - That fills the per browsing context role and whose optionally transient nature is already well spec'ed -CachedStorage - That fills Google's interpretation of the LocalStorage role in that it's global, and will probably be around on the disk in the future, maybe -FileStorage - That fills Apple's interpretation of the LocalStorage role in that it's global, and is as sacred as a file on the disk (or a song in your media library, or a photo in your photo library, or a bookmark, or...) The names are just suggestions at this point. Just for the record, I (now) agree with everything you said here.
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote: I started writing a detailed rebuttal to Linus's reply, but by the time I was finished, many others had already delivered more targetted replies. So I'll cut the rebuttal format and make a few specific points. - Many apps act as a shoebox for managing specific types of data, and users are used to using these apps to manage that data directly. See iTunes, Windows Media Player, iPhoto, and desktop mail clients as examples. This trend is growing, not waning. Browsers are already a shoebox for history, bookmarks, and other types of data. Claiming that this data is hidden from users who are used to handling obscure file management scenarios and therefore we shouldn't fully respect it is trying to fit in with the past, not trying to make the future better. - No one is suggesting that UAs not have whatever freedom they want in deciding *what* or *how much* to store. We're only suggesting that once the UA has committed to storing it, it *not* be allowed to arbitrarily purge it. - One use of LocalStorage is as a cache for data that is transient and non-critical in nature, or that will live on a server. But another, just-as-valid use of LocalStorage is for persistent, predictable storage in the client UA that will never rely on anything in the cloud. - And on that note, if developers don't have faith that data in LocalStorage is actually persistent and safe, they won't use it. I've given talks on this point 4 times in the last year, and I am stating this as a fact, based on real-world feedback from actual, real-world web developers: If LocalStorage is defined in the standard to be a purgable cache, developers will continue to use what they're already comfortable with, which is Flash's LocalStorage. When a developer is willing to instantiate a plug-in just to reliably store simple nuggets of data - like user preferences and settings - because they don't trust the browser, then I think we've failed in moving the web forward. I truly hope we can sway the LocalStorage is a cache crowd. But if we can't, then I would have to suggest something crazy - that we add a third Storage object. (Note that Jens - from Google - has already loosely suggested this) So we'd have something like: -SessionStorage - That fills the per browsing context role and whose optionally transient nature is already well spec'ed -CachedStorage - That fills Google's interpretation of the LocalStorage role in that it's global, and will probably be around on the disk in the future, maybe -FileStorage - That fills Apple's interpretation of the LocalStorage role in that it's global, and is as sacred as a file on the disk (or a song in your media library, or a photo in your photo library, or a bookmark, or...) In addition to the key/value pair storage apis, i think we'd need to make this distinction for databases and appcaches too. This distinction may be better handled in a way not tied to a particular flavor on storage. Or a similar distinction could be expressible within the database and appcache interfaces. window.openPermanentDatabase() / openPurgeableDatabase() manifest file syntax games: PURGEABLE or PERMANENT keyword in there somewhere. The names are just suggestions at this point. ~Brady
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 5:42 PM, Michael Nordman micha...@google.comwrote: In addition to the key/value pair storage apis, i think we'd need to make this distinction for databases and appcaches too. This distinction may be better handled in a way not tied to a particular flavor on storage. Or a similar distinction could be expressible within the database and appcache interfaces. window.openPermanentDatabase() / openPurgeableDatabase() manifest file syntax games: PURGEABLE or PERMANENT keyword in there somewhere. I think having authors choose between permanent and purgeable storage types adds complexity to the implementation and usage that is not desirable from either an authoring or a UX perspective. I continue to support Brady et al.'s vision of Local Storage. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 8:58 PM, Peter Kastingpkast...@google.com wrote: I think having authors choose between permanent and purgeable storage types adds complexity to the implementation and usage that is not desirable from either an authoring or a UX perspective. This complexity already exists for real apps, and developers seem fine with it. If you want persistent storage, you write to ~ or C:\Documents and Settings\ or such; if you want temporary storage, you write to /tmp or C:\temp\ or such. The distinction is useful to both users and developers, not burdensome. If authors can't say this can be thrown out if I haven't used it for a while, poorly-written apps will ignore the issue and store data forever. If they're storing small amounts of data, they probably won't run into any limits in testing, so they might not bother with handling out-of-space errors properly. So then eventually the garbage will accumulate until they run out of room and die, or bother the user pointlessly. A properly-written app, on the other hand, will be burdened with managing its own temporary storage. Authors will have to manually keep track of which of their resources are temporary and figure out when to remove them. Authors can't do this as well as the browser can. Authors don't know how much disk space is free, or how much space other apps are using, and they're in no position to decide how much disk space *should* be free. They might use too much disk space, or slow down their app by caching less for fear of using too much disk space. The browser should manage cache purging for the same reason the OS manages the page cache instead of applications.
Re: [whatwg] Web Storage: apparent contradiction in spec
I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog which reads, Please choose what to delete so that web sites will continue to work. The candidate delete list will be thousands long and hidden in that haystack will be a few precious needles. I also want to avoid any [Yes] [No] dialogs. Can I do something scary [Yes] [No]? Can I do something innocuous [Yes] [No]? Users shouldn't be forced to make those kinds of safety judgements. I'm guilty of instigating at least one of those dialogs. As shamed politicians do I'll retreat to the passive voice: Mistakes were made. I'm not opposed to web apps manipulating files on the user's computer, but the user should be in explicit control. I'd support input type=open and input type=save that worked similarly to input type=file. User agents are already registering for file types so that double clicking a file with a certain extension can be automatically sent to an URL, perhaps residing in an AppCache. In addition, I'd like to see the pop-up dialogs for the location API removed. I find the Can I know where you are? dialogs on the iPhone very annoying. Mistakes were made. Perhaps we can find a way to make input type=location work well instead. Linus On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote: I started writing a detailed rebuttal to Linus's reply, but by the time I was finished, many others had already delivered more targetted replies. So I'll cut the rebuttal format and make a few specific points. - Many apps act as a shoebox for managing specific types of data, and users are used to using these apps to manage that data directly. See iTunes, Windows Media Player, iPhoto, and desktop mail clients as examples. This trend is growing, not waning. Browsers are already a shoebox for history, bookmarks, and other types of data. Claiming that this data is hidden from users who are used to handling obscure file management scenarios and therefore we shouldn't fully respect it is trying to fit in with the past, not trying to make the future better. - No one is suggesting that UAs not have whatever freedom they want in deciding *what* or *how much* to store. We're only suggesting that once the UA has committed to storing it, it *not* be allowed to arbitrarily purge it. - One use of LocalStorage is as a cache for data that is transient and non-critical in nature, or that will live on a server. But another, just-as-valid use of LocalStorage is for persistent, predictable storage in the client UA that will never rely on anything in the cloud. - And on that note, if developers don't have faith that data in LocalStorage is actually persistent and safe, they won't use it. I've given talks on this point 4 times in the last year, and I am stating this as a fact, based on real-world feedback from actual, real-world web developers: If LocalStorage is defined in the standard to be a purgable cache, developers will continue to use what they're already comfortable with, which is Flash's LocalStorage. When a developer is willing to instantiate a plug-in just to reliably store simple nuggets of data - like user preferences and settings - because they don't trust the browser, then I think we've failed in moving the web forward. I truly hope we can sway the LocalStorage is a cache crowd. But if we can't, then I would have to suggest something crazy - that we add a third Storage object. (Note that Jens - from Google - has already loosely suggested this) So we'd have something like: -SessionStorage - That fills the per browsing context role and whose optionally transient nature is already well spec'ed -CachedStorage - That fills Google's interpretation of the LocalStorage role in that it's global, and will probably be around on the disk in the future, maybe -FileStorage - That fills Apple's interpretation of the LocalStorage role in that it's global, and is as sacred as a file on the disk (or a song in your media library, or a photo in your photo library, or a bookmark, or...) The names are just suggestions at this point. ~Brady
Re: [whatwg] brief question on 2.4.5 Dates and times
On Wed, Aug 26, 2009 at 11:12 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Aug 25, 2009 at 9:01 PM, Silvia Pfeiffersilviapfeiff...@gmail.com wrote: Hi, I am trying to use the specification of Dates and times given in section 2.4.5. I was surprised to find that there is a specification of a valid month string, but not of a valid year string or a valid day string. Is that an oversight? Isn't a valid day string just a normal date string? The month string is month-year, after all, not just month. A year string by itself isn't useful in the current spec, as there's nothing that would consume it. time uses a date or datetime, and the various inputs all use times, dates, weeks, or months. I suppose it is a matter of taste how to describe this. I'll give you my impression. I was trying to find out what restrictions we are putting on the year part of the string. E.g. are we allowing years before the year 0 and how. I went into the table of content and wasn't able to find anything about year, but only about month and date etc. By working backwards from the date, I found that the year string was defined under the month paragraph. I was rather frustrated by that time. Similarly with the format of the day string (i.e. the day part of the string, though that was much more obvious. It's all there, and it's all fully defined by recursive definition of the parts that are being re-used (e.g. date reuses month (which is month-year, but not just month). However, if you are trying to look for something, it's rather confusing not to have e.g. year and day exposed in the contents, while month is. As I said - a matter of taste - and possibly usability. Regards, Silvia.
Re: [whatwg] Web Storage: apparent contradiction in spec
This is one of those times when I *really* wish that the application developer community was more active on this list. I absolutely understand Linus' point of view, but I also feel like we are really hamstringing applications when we make choices like this and I wish that those developers were more vocally represented in these types of discussions. Going down this path would basically kill the ability to have offline web applications, because there would be no guarantees that the data would persist until the user comes back online. But since that point's already been made several times, I guess it's not a compelling argument. -atw On Wed, Aug 26, 2009 at 8:23 PM, Linus Upson li...@google.com wrote: I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog which reads, Please choose what to delete so that web sites will continue to work. The candidate delete list will be thousands long and hidden in that haystack will be a few precious needles. I also want to avoid any [Yes] [No] dialogs. Can I do something scary [Yes] [No]? Can I do something innocuous [Yes] [No]? Users shouldn't be forced to make those kinds of safety judgements. I'm guilty of instigating at least one of those dialogs. As shamed politicians do I'll retreat to the passive voice: Mistakes were made. I'm not opposed to web apps manipulating files on the user's computer, but the user should be in explicit control. I'd support input type=open and input type=save that worked similarly to input type=file. User agents are already registering for file types so that double clicking a file with a certain extension can be automatically sent to an URL, perhaps residing in an AppCache. In addition, I'd like to see the pop-up dialogs for the location API removed. I find the Can I know where you are? dialogs on the iPhone very annoying. Mistakes were made. Perhaps we can find a way to make input type=location work well instead. Linus On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote: I started writing a detailed rebuttal to Linus's reply, but by the time I was finished, many others had already delivered more targetted replies. So I'll cut the rebuttal format and make a few specific points. - Many apps act as a shoebox for managing specific types of data, and users are used to using these apps to manage that data directly. See iTunes, Windows Media Player, iPhoto, and desktop mail clients as examples. This trend is growing, not waning. Browsers are already a shoebox for history, bookmarks, and other types of data. Claiming that this data is hidden from users who are used to handling obscure file management scenarios and therefore we shouldn't fully respect it is trying to fit in with the past, not trying to make the future better. - No one is suggesting that UAs not have whatever freedom they want in deciding *what* or *how much* to store. We're only suggesting that once the UA has committed to storing it, it *not* be allowed to arbitrarily purge it. - One use of LocalStorage is as a cache for data that is transient and non-critical in nature, or that will live on a server. But another, just-as-valid use of LocalStorage is for persistent, predictable storage in the client UA that will never rely on anything in the cloud. - And on that note, if developers don't have faith that data in LocalStorage is actually persistent and safe, they won't use it. I've given talks on this point 4 times in the last year, and I am stating this as a fact, based on real-world feedback from actual, real-world web developers: If LocalStorage is defined in the standard to be a purgable cache, developers will continue to use what they're already comfortable with, which is Flash's LocalStorage. When a developer is willing to instantiate a plug-in just to reliably store simple nuggets of data - like user preferences and settings - because they don't trust the browser, then I think we've failed in moving the web forward. I truly hope we can sway the LocalStorage is a cache crowd. But if we can't, then I would have to suggest something crazy - that we add a third Storage object. (Note that Jens - from Google - has already loosely suggested this) So we'd have something like: -SessionStorage - That fills the per browsing context role and whose optionally transient nature is already well spec'ed -CachedStorage - That fills Google's interpretation of the LocalStorage role in that it's global, and will probably be around on the disk in the future, maybe -FileStorage - That fills Apple's interpretation of the LocalStorage role in that it's global, and is as sacred as a file on the disk (or a song in your media library, or a photo in your photo library, or a bookmark,
Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Wed, Aug 26, 2009 at 12:54 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher da...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.orgwrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already pretty
bad), because it willl make applications in visually unrelated tabs and
windows hang.
You can have script connections that span multiple tabs in multiple
windows, so in order to preserve the run-to-completion semantics of
JavaScript, it is important that
window.{alert,confirm,prompt,showModalDialog} be modal across all windows
in
the browser. This is why those APIs suck rocks, and we should never
create
APIs like them again.
I don't understand your point here. Are you saying that the current
firefox behavior is not correct, that releasing the storage lock on these
events is not correct, or something else?
I meant that the current Firefox behavior is technically incorrect. No
one likes app modal dialogs, but how else can you guarantee
run-to-completion semantics? How else do you prevent other scripts from
modifying your state while you are stuck calling into window.alert().
I don't know much about this issue, but it seems like something that
should either be fixed in Firefox (and other browsers?) or changed in the
spec. I'm interested to hear if others have thoughts on it.
Chrome and Safari both implement app-modal alerts. Firefox and IE
implement window modal, which is clearly buggy, but of course the world
hasn't imploded. I haven't tested Opera.
Personally, I would like to change Chrome to not put up app modal alerts.
I think it is bad UI, but I'm not sure how to do so without also breaking
the contract that JavaScript execution appear single threaded.
-Darin
Also, just for completeness, if you consider scoping an alert to a window,
then what happens when an alert is generated by another window? If each
alert is implemented using a nested event loop, then closing the first alert
will not return execution control back to the page that call alert.
So, the user will be left with a dead browser window. This is very similar
to the problem that exists with app modal alerts where one window is
inactive while another is showing an alert.
Without something like co-routines, I'm not sure how to solve this.
-Darin
Re: [whatwg] Web Storage: apparent contradiction in spec
I understand you want the web to be safe. I do too, and I think we all do. It never has been, it currently isn't, but it's better. The situation has been improving for many years. I'm not convinced that the idea of guaranteed persistent storage inherently takes us backwards. I think the current language in the spec (and whatever language we eventually settle on) allows user agents the flexibility to implement their own extra restrictions to accommodate its idea of safe while still guaranteeing the persistence of data it has claimed to store locally. I am convinced that if we change the language to solidify that LocalStorage is just a cache, we're discounting its use in offline web applications and the other examples of applications that desire local, persistent state and do not want a server/cloud component. We'd be driving these applications back to plug-ins, and I personally find that unacceptable. If that's what we're doing, then we haven't actually gained much with LocalStorage and might as well drop it. ~Brady On Aug 26, 2009, at 8:23 PM, Linus Upson wrote: I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog which reads, Please choose what to delete so that web sites will continue to work. The candidate delete list will be thousands long and hidden in that haystack will be a few precious needles. I also want to avoid any [Yes] [No] dialogs. Can I do something scary [Yes] [No]? Can I do something innocuous [Yes] [No]? Users shouldn't be forced to make those kinds of safety judgements. I'm guilty of instigating at least one of those dialogs. As shamed politicians do I'll retreat to the passive voice: Mistakes were made. I'm not opposed to web apps manipulating files on the user's computer, but the user should be in explicit control. I'd support input type=open and input type=save that worked similarly to input type=file. User agents are already registering for file types so that double clicking a file with a certain extension can be automatically sent to an URL, perhaps residing in an AppCache. In addition, I'd like to see the pop-up dialogs for the location API removed. I find the Can I know where you are? dialogs on the iPhone very annoying. Mistakes were made. Perhaps we can find a way to make input type=location work well instead. Linus On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote: I started writing a detailed rebuttal to Linus's reply, but by the time I was finished, many others had already delivered more targetted replies. So I'll cut the rebuttal format and make a few specific points. - Many apps act as a shoebox for managing specific types of data, and users are used to using these apps to manage that data directly. See iTunes, Windows Media Player, iPhoto, and desktop mail clients as examples. This trend is growing, not waning. Browsers are already a shoebox for history, bookmarks, and other types of data. Claiming that this data is hidden from users who are used to handling obscure file management scenarios and therefore we shouldn't fully respect it is trying to fit in with the past, not trying to make the future better. - No one is suggesting that UAs not have whatever freedom they want in deciding *what* or *how much* to store. We're only suggesting that once the UA has committed to storing it, it *not* be allowed to arbitrarily purge it. - One use of LocalStorage is as a cache for data that is transient and non-critical in nature, or that will live on a server. But another, just-as-valid use of LocalStorage is for persistent, predictable storage in the client UA that will never rely on anything in the cloud. - And on that note, if developers don't have faith that data in LocalStorage is actually persistent and safe, they won't use it. I've given talks on this point 4 times in the last year, and I am stating this as a fact, based on real-world feedback from actual, real-world web developers: If LocalStorage is defined in the standard to be a purgable cache, developers will continue to use what they're already comfortable with, which is Flash's LocalStorage. When a developer is willing to instantiate a plug-in just to reliably store simple nuggets of data - like user preferences and settings - because they don't trust the browser, then I think we've failed in moving the web forward. I truly hope we can sway the LocalStorage is a cache crowd. But if we can't, then I would have to suggest something crazy - that we add a third Storage object. (Note that Jens - from Google - has already loosely suggested this) So we'd have something like: -SessionStorage - That fills the per browsing
