Summary

  • W3C's 2009 Web SQL draft defined a browser API for local databases queried through a variant of SQL. The draft already warned that all interested implementors used SQLite and that pointing at SQLite was insufficient to specify a portable SQL dialect.
  • On 1 November 2010, the Web Applications Working Group agreed to republish Web SQL Database as a Working Group Note, taking it off the Recommendation track. The 18 November Note recorded the same independent-implementation impasse; W3C's 2011 storage survey described the SQL work as abandoned in favor of IndexedDB.

Standards meetings often ask whether two implementations can do the same thing. Web SQL seemed to have that much: its working group counted two. Then someone looked beneath the browsers. Both were running the same SQLite backend. If a web page behaved the same way in each, the result could prove that SQLite was consistent with itself. It could not establish that a third engine could reproduce a language defined by the document.

The December 2009 W3C Working Draft described an asynchronous API for local databases. A page could open a database, execute SQL in a transaction and read rows. The API was specified in detail. The language sent through it was the trouble. The draft called it a variant of SQL, then said all interested implementors had used SQLite and that the description of the dialect was still just a reference to SQLite. It expressly said that was unacceptable for a standard and invited someone willing to build an independent backend to come forward.

This was not a dispute about whether SQLite worked. In an April 2009 message to the W3C public-webapps list, Mozilla engineer Vladimir Vukicevic called himself a fan of SQLite and said he had advocated bringing it into Gecko. His objection was what happened when a browser exposed its particular SQL behavior to every site. SQLite had its own choices about syntax and data types. An app written against those choices might fail on another database engine. Telling browsers to “do what SQLite does” would make the engine, including its future behavior and security maintenance, part of the platform bargain. That was an engineer's argument in the standards discussion, not a measured report of broken applications.

The stakes were larger than one choice of storage library. A browser vendor could implement the Web SQL JavaScript surface and still face a choice it did not control: ship SQLite, or recreate its observed SQL dialect closely enough that existing web pages would behave the same. A website developer, meanwhile, could write code that worked in both current implementations and mistake that agreement for a browser-independent contract. The missing piece was a bounded SQL language that a different engine could implement from a document, with tests able to distinguish conformity from shared ancestry.

The W3C meeting minutes for 1 November 2010 capture the moment without ceremony. Participants noted two implementations but no will to push the specification forward. They observed that both sat on SQLite and that there was no separate specification for the subset of SQL involved. The group agreed to republish Web SQL Database as a Working Group Note. One participant said renewed interest could bring it back; another noted that re-entering the Recommendation track would require restarting the intellectual-property process. A Note kept the text available. It did not give it the standing of a Recommendation.

The Note published on 18 November 2010 made the verdict official: specification work had stopped because independent implementations were needed. Its section on the SQL language still instructed user agents to implement the dialect supported by SQLite 3.6.19. The document had described an API, but its query language remained pinned to one engine's version. W3C continued work on Web Storage and the Indexed Database API.

In its August 2011 survey of web application standards, W3C called the SQL-based browser database work abandoned in favor of IndexedDB. That statement describes the standards track. It does not date the removal of Web SQL from any deployed browser, and the documents here do not measure how many applications depended on it. The record does show a precise failure of proof: two implementations were not independent enough to tell the working group what the language actually was.

Original records