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:
sessionStoragesets fields on the window. When the window is closed, the session fields are lost, even if the site remains open in another window.
localStoragesets fields on the domain. Even when you close the browser, reopen it, and go back to the site, it remembers all fields in
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.
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
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
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
opener property that referred
to the old window, while in the old window you could store the return value of the
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
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.
I’ll be around at the following conferences:
Comments are closed.