A little while ago, I wrote about the dangerous point we’re at with HTML 5. At the time, I mentioned how browser vendors tend to jump on cool new things too quickly and that sometimes those things end up being removed and we’re left with incompatible implementations. Sadly, DOM Storage has become the first such example of the HTML 5 era.

In the first versions of HTML 5, inherited from Web Applications 1.0, DOM Storage consisted of two objects: sessionStorage and globalStorage. The former is used for session data only while the latter is used for storing data that persists across sessions. Firefox 2 implemented both objects, followed by Internet Explorer 8. The problem is that globalStorage has been removed from HTML 5 in favor of a localStorage object. WebKit, which just recently added DOM Storage in nightly builds, implemented sessionStorage and localStorage, which now means we have incompatible global storage data stores.

This is always the danger when implementing features described in a working draft. Browser vendors only rarely, if ever, remove features so it’s likely that globalStorage will stick around and ultimately will need to be added back into HTML 5. That leaves localStorage, arguably the better solution, as a third object that may or may not be implemented by other browsers.

Part of the problem is that HTML 5 is still under heavy development and refinement. The other part is that browser vendors are hotly competing with one another on features for developers, and everyone wants to be the first to implement a talked-about feature. At some point, this has to stop so that the ultimate vision of cross-browser compatibility can be achieved.

Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.

Both comments and pings are currently closed.