[whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement

Eric Uhrhane ericu at google.com
Tue Sep 14 16:47:07 PDT 2010


On Tue, Sep 14, 2010 at 4:30 PM, Jim Williams <jgwilliams at mindspring.com> wrote:
> I see localStorage and sessionStorage as a chance to fix things that weren't
> so good with cookies.  So I'd be interested to know what factors actively
> promote the failure to come up with a common browser-independent interface
> for localStorage.  Do browser builders actually have something to gain by
> resisting interoperability here?

I think you're coming at it from a quite different point of view than
browser builders usually have.  When we implement e.g. our
localStorage database, having it use the same file format as Opera is
the furthest thing from our mind.  Even if we wanted to share data
with them, how would we make sure that we didn't both write the file
at the same time?  How would we know when to update our in-memory
state from disk?  What if you had multiple Firefox profiles that each
used a different set of cookies--which profile should sync with Opera?

These are huge problems and lots of work, and for very little payoff.

> I'd also be interested to see some actual data on how often people switch
> browsers.  Much of my own browser-switching experiences have to do, not with
> web development, but with online courseware that was designed to run on a
> particular browser - and then I follow links on whatever browser I'm on at
> the moment, so that the same sites often turn up on both browsers. I also
> know nontechnical people who just like downloading and playing with stuff,
> including browsers.
>
> Also, yes, one could use the file system API in place of cookies or other
> local storage, but that tends to interrupt the user's flow of thought, so
> I'd prefer to avoid such heavy-handedness without having a good reason.
>
> Tab Atkins Jr. wrote:
>
> On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams <jgwilliams at mindspring.com>
> wrote:
>
>
> I tried out local storage, used it to save the contents of a
> content-editable passage.  It worked great in Firefox, Chrome, Safari, and
> MSIE.  Only one problem:  Every time I switched browsers, I had to start
> over with the original unedited passage.  So I have two requests.
>
> 1.  I would like the browser vendors to all use the same implementation of
> localStorage, as this will greatly facilitate browser-independent viewing
> experiences.  As it stands, I have no idea how to maintain continuity if a
> user viewing my page in one browser switches to another browser. None.
>
>
> Like cookies, all browser data will be dependent on the browser.
> There's very little chance of this ever changing.
>
> Users rarely switch browsers, in any case.  We web developers are a
> rare exception.
>
>
>
> 2.  Kindly extend the specification so that other applications can make
> constructive use of localStorage.  Specifically, (a) establish a convention
> for associating keys with particular files (e.g., by prepending the file's
> path name to the key), and (b) allowing other applications to treat the file
> and its associated local storage as a single entity.  Doing this would allow
> a user to e-mail the current state of a file to a friend, so that both will
> have the same view of the file.  This ability to share "current" views of a
> file is useful for maintaining HTML's role as a communications vehicle.
>
>
> The FileSystem API is designed for this use-case, so you can build a
> file in javascript and ask the user to save it to their harddrive.
>
> ~TJ
>
>
>



More information about the whatwg mailing list