JavaScript archives
Compatibility
Thidrekssaga
QuirksBlog
Donations
CSS book
Politics
Mobile
About
COH
I have started an HTML5 compatibility table today. For now it only contains a test of HTML5 Storage in all desktop browsers, and a short report is in order. I also retested the DOM HTML; no changes.
HTML5 Storage allows you to set some fields in what can best be described as a simple database in the browser. This allows you to retrieve such a value even when the user has closed his browser and reopened it.
Although in theory there’s little difference with cookies, HTML5 Storage is more useful because it doesn’t get sent to the server (less overhead), and because the fields can contain more information than a cookie (this feature is untested, BTW). These two advantages are clearest when you want to set a lot of values; for instance for a preference menu.
HTML5 Storage is supported by IE8, Firefox 3.5b4, and Safari 4. As yet Chrome and Opera do not support it.
Safari’s support is by far the best, because it is the only browser to also support the special properties of the new storage event.
IE8 supports HTML5 Storage in both IE8 and IE7 mode. A pure IE7 does not support HTML5 Storage.
There are two storage options:
sessionStorage sets fields on the window. When the window is closed,
the session fields are lost, even if the site remains open in another window.localStorage sets fields on the domain. Even when you close the
browser, reopen it, and go back to the site, it remembers all fields in
localStorage.Essentially, that means that the entire sessionStorage is cleared when the
user closes the browser window, while localStorage will remain available forever.
Except for this difference the two storage objects work exactly the same. The detail table contains a full breakdown of the rather simple API.
The specification
also defines a storage event that fires whenever a change is made to
a field. Safari requires you to define your event listener on the <body>; IE
requires it to be set on the document. Firefox doesn’t care.
The interesting part is that if you change a localStorage field this event fires
in all windows that contain a page of your site.
So if I’d open three QuirksMode.org pages in three tabs, and I’d
change the localStorage in one of them, the event fires in all three tabs.
Thus other pages can keep track of what’s going on and update themselves, if necessary.
This event needs some special properties in order to tell us which key was changed, what the old and the new value are, etc. Unfortunately only the Safari team has made an effort to implement them; Firefox supports only the least interesting property, and IE none at all.
By far the most interesting property is source, which refers to the window
in which the localStorage change took place.
By itself that’s only of moderate interest, but the consequence is that we now have a way of connecting windows that do not know of each other’s existence.
Remember: Safari only. IE and Firefox have not implemented this property.Until now, windows could only influence each other if they were aware
of each other’s existence; i.e. if one window was opened by the other by means of
JavaScript. In that case, the new window received an opener property that referred
to the old window, while in the old window you could store the return value of the window.open()
call (i.e. the new window) in a variable.
This was the only way of enabling cross-window communication. If a user manually opened two pages of your site in two windows, there was no way these windows could figure out each other’s existence.
With the coming of the source property this restriction is lifted.
When a storage event fires and you read out the source, you can now access the
window in which the event fired. In other words, you have created a reference from one window
to another.
In order to connect all windows that have your site in them, just register a storage event, change a field in one window, capture the events in the other windows, and create a variable. Now all other windows are connected to the first one, and a simple cross-window script will create a lookup table that gives all windows access to all other ones.
Although this sounds nice, I wonder if there are security repercussions.
Still, HTML5 Storage is here to stay, and it will be especially important on mobile phones, which, as always, suffer from worse data connections than desktop browsers. I’ll run the tests on the mobile browsers later.
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
Comments are closed.
1 Posted by Mikael Abrahamsson on 12 June 2009 | Permalink
I agree, this is something all mobile phone browsers who want to call them self a browser should support.
2 Posted by Elijah Grey on 12 June 2009 | Permalink
I think you should note that this code snippet can provide a workaround for Firefox 2 and 3:
if (typeof localStorage == "undefined" && typeof globalStorage != "undefined")
const localStorage = globalStorage[location.hostname];
It supports every method except clear() and can be easily implemented by using removeItem() and key().
3 Posted by Brian Kuhn on 12 June 2009 | Permalink
Thanks for this. I'd like to see the async and defer attributes for script tags added.
http://dev.w3.org/html5/spec/Overview.html#attr-script-async
I'm currently trying to track down this information by doing my own tests. So far, no one seems to support async :(
4 Posted by Doeke Zanstra on 12 June 2009 | Permalink
@Elijah: nice workaround. But remember, you don't get cross domain security.
5 Posted by Peter Robinett on 13 June 2009 | Permalink
Hi PPK, just a quick comment on your introduction: I think you're giving HTML5 storage short shrift. It uses a basic SQL database, with all the querying you can do in SQL, and can be used for a lot more than simple key-value storage. On the iPhone, databases can be up to 5 mb, while in Safari on the desktop I believe they can be 10 mb. Because of these advantages, you can do very interesting things like store all your email headers locally, which Gmail has essentially done.
Minor nitpicking aside, thanks for looking into vendor support of HTML5 storage and thanks for introducing the source property to me – I didn't know about that. I look forward to your future tests!
6 Posted by Brian LePore on 15 June 2009 | Permalink
I'm on the fence about HTML5 Storage. Excluding the situations where you KNOW that the browser your users are using support it (e.g. mobile devices?), it doesn't seem like something that can really be used at this point. Any feature I can think of that would benefit from this I am going to want to work in at least IE7, if not IE6 as well. This means the typically cludge involved to do it all server side for them... and if you're already doing it server-side for some why not just do it for all and save yourself the hassle of maintaining two code bases (this ignores the argument that you should be doing something for people with JavaScript off to begin with). Am I alone in feeling like this? I'm all for the benefits of HTML5, I just can't think of how this can be useful any time soon. :(
7 Posted by Pirate Party on 15 June 2009 | Permalink
A quick suggestion: surely you don't need the columns for older browsers for this sort of thing (IE5.5, IE6, FF2 etc.) - it might make it easier to read, otherwise you'll end up with acres of red that's not really necessary.
It's a minor nitpick - really good to have the table.
8 Posted by Lennie on 16 June 2009 | Permalink
Their is also Google Gears, which might be available on some computers (unsure how many, it does come with some of their software (Chrome for instance, but I think also Desktop and Toolbar)) but I've not tried that yet.
9 Posted by David Dabbs on 31 July 2009 | Permalink
What about postMessage? I can't find any compatibility tables on QuirksMode regarding it.
Thanks, dd