[whatwg] localStorage feedback

Brett Cannon brett at python.org
Tue Oct 13 11:34:41 PDT 2009

On Mon, Oct 12, 2009 at 19:07, Ian Hickson <ian at hixie.ch> wrote:

> [SNIP]
> On Wed, 23 Sep 2009, Brett Cannon wrote:
> >
> > Before the move to structured clones one could tell if a key was set by
> > calling getItem() and seeing if it returned null (had to use === as
> > someone could have called setItem() w/ null, but that would be coerced
> > to a string for storage). But with the latest draft's switch to
> > structured clones that test no longer clearly differentiates between
> > whether the value returned by getItem() signifies that the key was not
> > set, or the key was set with the value null.
> I believe you can test if a key is in the storage area using:
>   if (key in storage) { ... }
> For example:
>   if ('document' in window.localStorage) { ... }
I didn't find that in the spec anywhere. Is it somehow implicit and I just
missed it? Or will it be specified sometime in the future?

> > And since I just subscribed to the mailing list, I was wondering if the
> > whole workers/localStorage discussion ended or not, as I can provide a
> > (potentially minor) real-world use-case for sharing access between the
> > page and worker if people want to hear it (in a new email of course).
> I think everyone agrees that we need a storage mechanism in workers; the
> question is what it should be. That's basically the same as the question
> of what should happen with the Web Database spec -- I don't think we would
> want to end up with multiple storage systems in workers. The answer to
> this question depends on the result of this debate in the Web Apps WG.
Since I am not a w3c member and thus cannot subscribe to the Web Apps WG
mailing list, just want to say good luck to whomever pushes this. I truly
hope you guys can agree on a single storage solution that the browsers all
implement. It would definitely help keep my PhD thesis relevant after it's
finished. =)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091013/8fe1e2ad/attachment-0001.htm>

More information about the whatwg mailing list