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'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 <[email protected]> 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

  

Reply via email to