Right now it's defined as "What SQLite does", which is not a way to implement a standard.
Not to mention that even if they did create a full "specification" for the SQL that it uses, it seems like way too much to force onto a browser to develop for not all that much benefit.
Safari and Chrome both support it, but it's not going to get any major updates and only exists in the browser today because it was added at one point.
The cut-down SQL would include just the basics: CREATE TABLE, CREATE INDEX, INSERT, UPDATE, DELETE, SELECT. No triggers or views. No support for partial indexes or indexes on expressions, common table expressions, or other such features. There would be a minimal set of built-in SQL functions, but with support for application-defined SQL functions written in javascript.
A competing implementation would not need to understand the SQLite file format nor the complete SQLite language nor would it need to implement the SQLite API. All it would need to do is support the basic SQL subset defined by the spec.
If you get the browser vendors on-board with this idea, and I'll write the spec.
But if someone out there has experience working with whatwg or W3C on these kinds of things and wants someone to help out, I'd love to be a part of it.
But like you said, the hardest part is getting the different browser engines to promise support (or even take it seriously). I remember reading on HN a post from a woman who was involved in trying to get SVG in the browser standardized (sadly I can't seem to find it any more!), and just reading about the struggles she went through to even talk to someone involved who, while receptive, basically told her that it wasn't going to get done.
It seems like there would need to be an "advocate" who is part of the teams on EdgeHTML and Gecko that would be willing to fight for it before it would even begin, otherwise, like you said, it would all basically be wasted effort.
The JavaScript standardization system is quite nice, I wish that browsers could get together and come up with something similar for Web APIs...
BUT... what about making an exception to the rule? SQLite is sort of a unique beast -- public domain license, used almost everywhere (most smart phones have it embedded, Chrome and Safari have it), and rock solid? Also, it's not like it's a 100 million LOC app.
A real spec is "loose", it allows wiggle room in many areas, it allows for multiple ways to implement things, it allows implementations to act differently, and in most cases that comes out as a win for the user. Saying the spec should do what a single implementation does is about as close to saying "you aren't allowed to improve this" as you can get.
I really believe that a monoculture is a bad thing. Luckily on most platforms SQLite (while the best in most cases) doesn't have a monopoly on what it does, and while it's a "defacto" standard in many cases, there are alternatives at every step of the way. Saying that a platform must implement SQLite takes that defacto standard and codifies it. It's forcing a monoculture. It doesn't just deincentivise improvement, it almost explicitly forbids it.
For example, javascript changes can't be put into a standard until they have (IIRC) 3 major browsers which implement them.
Pinning a standard to a specific implementation (and a specific version) is the opposite of every other web standard. Plus it means that any alternate implementations must reimplement SQLite themselves if they don't want to or can't use SQLite themselves.
If you're referring to SQLite itself being implemented multiple times, I don't understand why that's relevant to Web SQL. You wrote that Web SQL shouldn't be supported, i.e. implemented, until there's a spec. It seems like there's a 'spec' now, if not an official formal spec. But now you're claiming that Web SQL can't be a standard because there aren't multiple implementations. But it certainly seems like there are already multiple implementations:
- [Can I use... Support tables for HTML5, CSS3, etc](https://caniuse.com/#feat=sql-storage)
But still, your logic seems circular: Web SQL shouldn't be implemented for all the browsers because there's no spec and there's no spec because there aren't multiple implementations.
I imagine there's a distinction you're trying to convey that I'm missing. What is it?
It is a bit circular, but generally something gets proposed as a standard, multiple browsers will implement it, then it becomes a finalized standard.
In this case it was proposed, the standard says "your implementation needs to do what this other implementation does" (and no other information is given about the SQL system), 2 browsers (really 1 engine at the time, webkit) used SQLite directly, and it never went anywhere else.
I guess my point isn't that there's not a "spec", but that the spec that there is doesn't say anything about the SQL part of WebSQL, it just says what the interface to the SQL engine looks like, and then mandates that the SQL engine act, look, and work like the one in a specific version of SQLite.