Re: [whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

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  
 and  that worked similarly to  
. 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  work well instead.


Linus


On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson   
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 w

Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)

[Darin Fisher]

On Wed, Aug 26, 2009 at 12:54 PM, Darin Fisher  wrote:

> On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow wrote:
>
>> On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher wrote:
>>
>>> On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow wrote:
>>>
 On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher 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().
>>>
>>
>> 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

[Drew Wilson]

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  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  and
>  that worked similarly to . 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  type="location"> work well instead.
>
> Linus
>
>
> On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson  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
>> i

Re: [whatwg] brief question on 2.4.5 Dates and times

[Silvia Pfeiffer]

On Wed, Aug 26, 2009 at 11:12 PM, Tab Atkins Jr. wrote:

> On Tue, Aug 25, 2009 at 9:01 PM, Silvia
> Pfeiffer 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.   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

[Linus Upson]

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  and
 that worked similarly to . 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  work well instead.

Linus


On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson  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] Web Storage: apparent contradiction in spec

[Aryeh Gregor]

On Wed, Aug 26, 2009 at 8:58 PM, Peter Kasting 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

[Peter Kasting]

On Wed, Aug 26, 2009 at 5:42 PM, Michael Nordman wrote:

> 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

[Michael Nordman]

On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson  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

[Jeremy Orlow]

On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson  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

[Remco]

On Thu, Aug 27, 2009 at 2:26 AM, Peter Kasting wrote:
> On Wed, 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.
>
> 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

[Peter Kasting]

On Wed, 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.
>

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

[Michael Nordman]

> 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  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

[Michael Nordman]

On Wed, Aug 26, 2009 at 5:08 PM, Remco  wrote:

> On Thu, Aug 27, 2009 at 1:55 AM, Michael Nordman
> 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

[Brady Eidson]

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

[Peter Kasting]

On Wed, Aug 26, 2009 at 5:08 PM, Remco  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

[Remco]

On Thu, Aug 27, 2009 at 1:55 AM, Michael Nordman 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

[Jens Alfke]

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

[Michael Nordman]

> 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  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

[Michael Nordman]

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  wrote:

> On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman wrote:
>
>> 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

[Jens Alfke]

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

[Peter Kasting]

On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman wrote:

> 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

[Michael Nordman]

> 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  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  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 th

Re: [whatwg] Web Storage: apparent contradiction in spec

[Peter Kasting]

On Wed, 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. 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 'pr

Re: [whatwg] Web Storage: apparent contradiction in spec

[Linus Upson]

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 different
than that for web pages. Non-browser UAs such as Dashboard, AIR, etc. may
have different policies.

If the spec requires UAs to maintain local storage as 'precious' it will be
the first such feature in HTML 5. Everything else in the spec is treated as
volatile.

Linus


On Tue, Aug 25, 2009 at 4:36 PM, Jeremy Orlow  wrote:

> On Tue, Aug 25, 2009 at 4:18 PM, Brady Eidson  wrote:
>
>>
>> On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote:
>>
>> On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman  wrote:
>>
>>> On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow
>>> wrote:
>>>
>>> Extensions are an example of an application that is less cloud-based.
>>> It would be unfortunate and weird for extension developers to have to
>>> worry about their storage getting tossed because the UA is running out
>>> of disk space.
>>
>>
>> Extensions are pretty far out of scope of the spec (at least for now),
>> right?  (Within Chrome, we can of course special case this.)
>>
>>
>> The current spec is about "Web Applications" of all forms, including those
>> that are offline, and others that hope to break from from the *required*
>> chain to the cloud.
>>
>> E

[whatwg] Note on the DETAILS element

[Jeremy Keith]

The text for  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:


Dr. Strangelove
Or: How I Learned to Stop Worrying and Love the Bomb


...but wouldn't be true in this case:


Dr. Strangelove
Or: How I Learned to Stop Worrying and Love the Bomb


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.:



Dr. Strangelove
Or: How I Learned to Stop Worrying and Love the Bomb
By Stanley Kubrick


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] Storage mutex and cookies can lead to browser deadlock

[Jeremy Orlow]

On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan wrote:

> On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow  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.

Re: [whatwg] Storage mutex and cookies can lead to browser deadlock

[Robert O'Callahan]

On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow  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?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Storage mutex and cookies can lead to browser deadlock

[Jeremy Orlow]

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  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  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

[Drew Wilson]

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  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

[Jens Alfke]

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

[Drew Wilson]

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  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
>
>

[whatwg] Storage mutex and cookies can lead to browser deadlock

[Jens Alfke]

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] HTML5 History Management

[Mike Wilson]

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

Re: [whatwg] Storage mutex

[Darin Fisher]

On Wed, Aug 26, 2009 at 12:49 AM, Darin Fisher  wrote:

> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan 
> wrote:
>
>> On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow wrote:
>>
>>>
>>>  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] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)

[Darin Fisher]

On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow  wrote:

> On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher  wrote:
>
>> On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow wrote:
>>
>>> On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher 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().
>>
>
> 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

[whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)

[Jeremy Orlow]

On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher  wrote:

> On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow  wrote:
>
>> On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher 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().
>

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] Storage mutex

[Darin Fisher]

On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow  wrote:

> On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher  wrote:
>
>> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan > > 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

Re: [whatwg] Storage mutex

[Jens Alfke]

On Aug 25, 2009, at 10:36 PM, Jeremy Orlow wrote:

What about yieldStorageMutex?  Yield is enough different from unlock  
that I don't think it'll leave developers looking for the lock  
function.  Yield fits pretty well since this is essentially  
cooperative multi-tasking.  StorageMutex is good because that's what  
its actually affecting.


+1 ... "yield" is a good established term for this sort of behavior.

(At a higher level, though, I'm still uncomfortable with semantics  
that allow a poorly-written worker thread to indefinitely lock up JS  
code running in web pages.)


—Jens

Re: [whatwg] Web Storage: apparent contradiction in spec

[Adrian Sutton]

On 26/08/2009 18:36, "Jens Alfke"  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 
Ephox Blogs , Personal Blog

Re: [whatwg] Web Storage: apparent contradiction in spec

[Aaron Whyte]

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  wrote:

> On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlow 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

[Jens Alfke]

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] Microdata

[Brian Campbell]

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:


  http://example.com/products/bt200x";>
  GPS Receiver BT 200X
  Rating: ⋆⋆⋆✩✩ item=rating content="2">

  Release Date:
January 22
  http://ln.hixie.ch/";>Ian
:
"Lots of memory, not much battery, very little
   accuracy."


  
  
My Pond
Licensed under the http://www.opensource.org/licenses/mit-license.php";>MIT
  license.
  



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:

  Some text. A link. Some  
more text


Result in:

  // http://example.org/sample/test
  { "foo": [ "Some text. A link. Some more text" ] }

While simply changing link an item:

  Some text A linka>. Some more text


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] Adding alpha channel to

[Nils Dagsson Moskopp]

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 
> 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

Re: [whatwg] brief question on 2.4.5 Dates and times

[Tab Atkins Jr.]

On Tue, Aug 25, 2009 at 9:01 PM, Silvia
Pfeiffer 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.   uses a date or datetime, and
the various inputs all use times, dates, weeks, or months.

~TJ

Re: [whatwg] Adding alpha channel to

[Tab Atkins Jr.]

On Wed, Aug 26, 2009 at 2:35 AM, Max Romantschuk wrote:
> Victor Vasiliev wrote:
>>
>> I suggest to add a boolean attribute "alpha" to 
>> (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 
suggestion.)

CSS has also trained many of us authors that alpha is a component of
colors with its rgba() syntax.

~TJ

Re: [whatwg] Storage mutex

[Adrian Sutton]

On 26/08/2009 12:36, "Kevin Benson"  wrote:
> "... _enables_ others to update storage."
> 
> grantStorageUpdates

allowStorageUpdates ?

Regards,

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 628 200 182 x481  US: +1 (650) 292 9659 x717
Ephox 
Ephox Blogs , Personal Blog

Re: [whatwg] Storage mutex

[Kevin Benson]

On Wed, Aug 26, 2009 at 1:28 AM, Robert O'Callahan wrote:
> On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow  wrote:
>>
>> To me, getStorageUpdates seems to imply that updates have already happened
>> and we're working with an old version of the data.  I think many developers
>> will be quite shocked that getStorageUpdates _enables_ others to update
>> storage.  In other words, 'get' seems to imply that you're consuming state
>> that's happening anyway, not affecting behavior.
>
> fetchStorageUpdates?
>

"... _enables_ others to update storage."

grantStorageUpdates

-- 
-- 
   --
   --
   ô¿ô¬
K e V i N
   /¯\

Re: [whatwg] formNoValidate/novalidate/willValidate

[Simon Pieters]

On Wed, 26 Aug 2009 06:14:15 +0200, Peter Kasting   
wrote:


On Tue, Aug 25, 2009 at 7:56 PM, Dean Edwards  
wrote:



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] formNoValidate/novalidate/willValidate

[Michelangelo De Simone]

2009/8/26 Dean Edwards :

> "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] Web Storage: apparent contradiction in spec

[Anne van Kesteren]

On Wed, 26 Aug 2009 00:59:31 +0200, Aaron Boodman  wrote:

On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlow 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] Storage mutex

[Jeremy Orlow]

On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher  wrote:

> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan 
> 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?

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] Storage mutex

[Darin Fisher]

On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan wrote:

> On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow wrote:
>
>> On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan 
>> wrote:
>>
>>> On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow wrote:
>>>
 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

[Darin Fisher]

On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan wrote:

> On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow wrote:
>
>> On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan 
>> wrote:
>>
>>> On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow wrote:
>>>
 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] Adding alpha channel to

[Max Romantschuk]

Victor Vasiliev wrote:

I suggest to add a boolean attribute "alpha" to 
(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] Text areas with pattern attributes?

[Max Romantschuk]

Smylers wrote:

The point is to have cases specifically _for_ it -- not adding
everything for which there isn't a reason against.

If  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  and  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/