Google has announced support for the HTML 5 Web SQL Database API, and others are likely to follow soon or have already started on support for this API. In the meantime, the completion of the specification is blocked because all the implementers involved have chosen to use SQLite as underlying database, and multiple independent implementations are required for standardization.
As part of HTML 5, the W3C organization is working on a draft of the Web SQL Database API, a specification which covers storing and accessing data through SQL. The SQL language dialect which is described in the documentation is that of SQLite 3.6.19. This API allows web pages to contain code that interacts with an embedded client database, which is useful for applications wanting to store data locally or for offline browsing.
Google has announced support for Web SQL Database in the latest production version of their browser, Chrome 4, based on SQLite. This is a move toward standardization considering Google has a Database API, also based on SQLite, in Gears. Through the Gears API, structured data storage was provided for all major browsers, including IE, Firefox, and Safari; however, Google has stopped developing Gears.
Firefox 3 has an embedded SQLite database which is currently used mostly for storing bookmarks and history, but it will probably add support for Web SQL Database API. Work is underway on WebKit, the rendering engine used by Safari, to make the Web Database API available to web workers. Nothing is currently known about Microsoft’s plans for IE and the HTML 5 database API.
While some companies have implemented the Web Database API and others are working on implementing it, the specification has reached a roadblock according to the draft because all interested parties have chosen to use SQLite:
This specification has reached an impasse: all interested implementers have used the same SQL backend (SQLite), but we need multiple independent implementations to proceed along a standardization path. Until another implementer is interested in implementing this spec, the description of the SQL dialect has been left as simply a reference to SQLite, which isn't acceptable for a standard. Should you be an implementer interested in implementing an independent SQL backend, please contact the editor so that he can write a specification for the dialect, thus allowing this specification to move forward.
Given this “impasse”, it remains to see if the standard will drive the implementation or if it will be the other way around. At present, it appears that Google has driven an increase in the pace of browser development, and none of the browser vendors are waiting for the standards to complete before implementing their own Web SQL Database API support.
Community comments
Underway in WebKit?
by Ivo Limmen,
Re: Underway in WebKit?
by Bart Guijt,
there's always a roadblock if you want one...
by Gabor Ratky,
Re: there's always a roadblock if you want one...
by Stefan Wenig,
Waiting for Microsoft
by Tim Howland,
Re: Waiting for Microsoft
by Jay Godse,
Re: Waiting for Microsoft
by Dan Tines,
Re: Waiting for Microsoft
by Venkatramanan Sastry,
Underway in WebKit?
by Ivo Limmen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Strange to read that WebKit is still developing this feature as Chrome uses WebKit.
Re: Underway in WebKit?
by Bart Guijt,
Your message is awaiting moderation. Thank you for participating in the discussion.
The regular 'async' API is in WebKit for two years IIRC, the recent 'synchronous' API is not. That part of the API would also benefit greatly by running in a web worker.
there's always a roadblock if you want one...
by Gabor Ratky,
Your message is awaiting moderation. Thank you for participating in the discussion.
I find it funny that the fact that everyone chose SQLite (a smart and logical move by everyone) is now blocking the standardization effort. Yes, it would be great to see the standard work well with multiple implementations but once in a lifetime, when everyone agrees on something, why not just be happy about it? Life would be a lot easier on the HTML5 <video> front as well if companies weren't fist fighting over H.264, Ogg and whatever else they come up with.
Or maybe standardize the SQLite dialect as a 'portable SQL dialect' and get on with it.</video>
Waiting for Microsoft
by Tim Howland,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm sure Microsoft will just use Access, or embed excel, or something similarly inane.
Re: Waiting for Microsoft
by Jay Godse,
Your message is awaiting moderation. Thank you for participating in the discussion.
I bet that Microsoft will use SQLite. Their current problem is that Firefox, Chrome, and Safari have taken away enough market share that taking IE in a proprietary direction with respect to HTML5 storage could easily kill IE.
Re: there's always a roadblock if you want one...
by Stefan Wenig,
Your message is awaiting moderation. Thank you for participating in the discussion.
Not without irony. But if you think about it - when there's just one implementation, what problem would standardization solve?
Re: Waiting for Microsoft
by Dan Tines,
Your message is awaiting moderation. Thank you for participating in the discussion.
Only when and if HTML 5 (and specifically the Database API) is relevant years from now.
Re: Waiting for Microsoft
by Venkatramanan Sastry,
Your message is awaiting moderation. Thank you for participating in the discussion.
Now that the MS SQL Server Express is free and is the desktop offering of their SQL Engine, it would be wise for Microsoft to use MS SQL Server Express.
If I recollect correctly, they haven't been consistent with their approach when it comes to storage (Microsoft Outlook still uses a proprietary format for data storage).