WebSQL is SQLLite and making that a standard is very hard without including SQLite's bugs and non-standard behavior.

Mozilla had really good reasons for shooting it down. Calling them out on it is meaningless without specifying why you think they've been wrong. You can say anything about IndexedDB, but at least it has a spec.

> SQLite's bugs and non-standard behavior.

"Bugs" I get, but what do you mean by "non-standard behavior" mean here?

My perspective, having had some experience with some pretty sophisticated DB adapter layers in the past: SQLlite and other nominally-SQL DBs all have only a very superficial level of SQL-level compatibility. Aside from closely related DBs (e.g. forks) it's not like there's any actual ability to exchange character-for-character identical SQL or DDL between DBs. All kinds of things like quoting, namespacing, and so on have subtly different syntax. It's pretty easy for a human to switch between SQL-x and SQL-y systems, but not so much when you're talking query generation. Even Rails has a pile of different backends for Active Record, and AR's backend is pretty darn simplistic.

SQLite is kind of different from other DBs, in various ways. For example, data types,

http://www.sqlite.org/datatype3.html

It should be compatible with most DBs, but SQLite has more dynamic types, and supports more things, in ways that are "odd" for almost all other DBs. As you correctly said, in general, no two DBs are easily interchangeable, and SQLite is no exception, perhaps it is even more of an outlier in fact.

That means that to implement SQLite, not using SQLite code, means you need to carefully reproduce that behavior, and all aspects of it - in practice, including bugs - to be a compatible web browser. For a web standard, that's just unacceptable.

* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature. SQLite is in public domain, so every company can use it (even Microsoft products already use it!)

* Also the argument of them that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog).

Nowadays with the rise of NewSQL movement of people who burnt their fingers with NoSQL, one can only hope someone gives some love to Web SQL.

To sum up, NoSQL has it's place and SQL has one too.

We had this discussion already this week, hopefully W3C board members and Mozilla devs read this: https://news.ycombinator.com/item?id=9082847

> The argument that WebSQL was tailored to a specific SQLite version is nonsense.

No, the idea that WebSQLDB was not tailored to a specific SQLite version is nonsense. See Section 5 of the last version of the WebSQLDB spec [0]:

User agents must implement the SQL dialect supported by Sqlite 3.6.19.

> SQLite supports the official SQL92 standard

SQLite version 3.6.19 does not support all of, or only, the SQL92 standard. WebSQLDB did not mandate support for the SQL92 standard, or any other standard version of SQL, it specified the dialect supported by SQLite 3.6.19.

[0] http://www.w3.org/TR/webdatabase/#databases

> Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved.

Everyone does not know this. Some people believe this, other people believe it should die in a fire. But whatever one things about the current state of the abandoned WebSQLDB spec, that is what WebSQLDB is, and you can't talk about -- honestly, at least -- it and pretend that it specifies SQL-92 as the required SQL dialect when, in fact, it specifies "the SQL dialect supported by SQLite 3.6.19".

You are essentially arguing that WebSQLDB should not have been abandoned based on the content of an imaginary WebSQLDB spec that never existed. If WebSQLDB had specified a (explicit, well-defined, use-case appropriate, single-user subset of) SQL-92 that would be different than what it actually specified, and the discussion would be different.

> About 95% of all mobile devices already support WebSQL

Yes, they are embedding SQLite. That's not a standard, it's a hack.

> The only missing browsers are IE 11 and Firefox/FirefoxOS

Which is why I'm glad they are still relevant.

> The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others.

Nobody ever said WebSQL was intended to require a specific version of SQLite. But nearly every browser would have used SQLite, and experience has shown that when you expose functionality to the web, sites start depending on specific implementation quirks - check out all the gibberish people used to feed to IE6's CSS parser to trick it into behaving.

Also, note that SQLite is not what most people think of when they talk about SQL databases, if only because of its very "manifest typing". Maybe SQL92 is flexible enough to permit such things, but code written for SQLite is very likely to break horribly on other SQL implementations.

* There is a common misconception about SQLite3 dynamic type system. It can be done using SQL statements: http://stackoverflow.com/a/2762020, http://www.sqlite.org/datatype3.html . The browser vendors could enable static typing by default by adding a few lines of code or just a flag afaik. Beside that there are other SQL db engines. SQL-92 was the third revision of the SQL database query language. It's the common dialect that every SQL engine supports: http://en.wikipedia.org/wiki/SQL-92

* Beside that even if Microsoft would use JetRed (http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine) or JetBlue (http://en.wikipedia.org/wiki/Microsoft_JET_Blue) database engine and use a slightly different SQL dialect, everyone else would use SQLite anyway (and even Microsoft products like several Xbox games and Tools use SQLite). It's the same like supporting different XHR/AJAX API versions (like the ActiveX API calls of < IE9) or many other glitches. One could use a shim.

Without WebSQL support one has to compile SQLite via emscripten to asm.js -> 3 MB big JS file.

Or you know, one could use IndexedDB, because you don't need a freaking relational model, unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser.

> everyone else would use SQLite anyway

That does not make it a web standard and after 25 years of web evolution, I can't believe we are still having the same problems. The web has been extremely successful for some obvious reasons, yet we keep forgetting those reasons. One of the web's primary traits is that it's based on documented standards and has multiple implementations. SQLite fails that test.

> One could use a shim

Or you could not have this problem in the first place. And technically you could implement WebSQL on top of IndexedDB.

> unless you're planning to execute ad-hoc queries and aggregation on a significant amount of data, data that would do well to fit the relational model, which would be a stupid idea to do in the browser.

You mean like every iOS app that uses Core Data? And web apps will kill native apps with an approach like this?

> SQL-92 was the third revision of the SQL database query language.

And is completely irrelevant to WebSQLDB, which specifies "the SQL dialect supported by SQLite 3.6.19" -- not SQL-92 -- as what implementations must support. The SQL dialect supported by SQLite 3.6.19 does not include all of SQL-92, and includes extensions to SQL-92, so supporting SQL-92 would be neither necessary nor sufficient, from a supported SQL standpoint, to conform to the WebSQLDB spec.

I've done a ton of work with contenteditable and it's not especially good on IE (it was especially bad on IE up to IE8) nor especially bad on Safari (it's kind of horrible, but it's horrible everywhere).

I edited my text, I meant: Safari on iOS. The touch interface introduces bugs that haven't been fixed for years. Desktop Safari is as buggy as Chrome, both originally based on the same Webkit code.

GoogleDocs v2, Word WebApp and iCloud Pages use a JavaScript based page layout engine that renders one DIV per line and don't use the contenteditable. Even the blinking cursor is a DIV. Though, even they do not support text-columns - something that would work out of the box with contenteditable. (GoogleDocs v1 used contenteditable, as well as SharePoint content editor and its first Word WebApp incarnation)

Implementing such a complex page layout engine plus internal document format (XML based?) is a lot of work and afaik there is no such open source JS library exists.

Agreed, contenteditable is terrible in Safari for iOS.

Pages actually uses SVG for most of its layout. It makes me suspect that Apple has an XCode back end for compiling Cocoa/IB code to Javascript.

Agreed. For instance, IE (11 at least) doesn't permit <td> cells contenteditable. There are some workarounds, but then other browsers seem to have problems.