Summary

  • W3C 的 2009 年 Web SQL 草案定义了网页访问本地数据库的接口，却承认所有有意实现它的开发者都使用 SQLite；仅引用 SQLite 的 SQL 行为，不足以写成独立的标准。
  • W3C Web Applications 工作组于 2010 年 11 月 1 日同意把草案改发为工作组说明，退出推荐标准轨道。11 月 18 日的正式说明记录了这一僵局；W3C 的 2011 年概览转而把 IndexedDB 列为继续推进的方向。

标准组织喜欢数实现。数到两份，听上去已有互操作性的证明。Web SQL 把这个算术玩笑推到了台前：两份实现背后的 SQL 解释工作，都交给 SQLite。网页查询在两处得到同样回答，可能只是因为它问了同一个人两次。真正困难的是，让第三方只读规范、不复制 SQLite，也能给出同样回答。

2009 年 12 月的 W3C 工作草案 描述了一个异步接口：打开数据库，在事务里执行 SQL，再读取结果。JavaScript 调用方式有相当细的规定。SQL 语言本身却被称作一个“变体”。草案直接写出障碍：有兴趣的实现者都采用 SQLite，方言说明只剩对 SQLite 的引用；这不足以成为标准。编辑还公开邀请愿意做独立后端的人加入，以便真正写出语言边界。

这不是“SQLite 不好用”的故事。Mozilla 工程师 Vladimir Vukicevic 在 2009 年 4 月发给 W3C 公开邮件列表的讨论中，先说自己喜欢 SQLite，也曾支持把它放进 Gecko。他担忧的是网页会开始依赖 SQLite 对语法和数据类型的具体选择。若换一台数据库引擎，同一段网页查询可能不再工作。让浏览器“照 SQLite 的方式做”，还意味着每家浏览器都要承担这套代码的后续行为与安全维护。这是参与者当年的技术判断，并非已经测得多少网站故障。

网站开发者最容易看错这一幕。一条查询在两款浏览器上都通过，就像获得了通行证。但如果两者的共同点是 SQLite，那么查询可能依赖的是同一套未被规范明确划定的习惯。第三家浏览器若想换后端，只能追着旧引擎的实际行为模仿，或者冒着破坏页面的风险。工作组需要的是独立定义的 SQL 子集和能区分“遵守文档”与“共用代码”的测试。

2010 年 11 月 1 日的 W3C 会议记录把决定记得很平实：有两份实现，推进意愿却不足；它们都建在 SQLite 上，涉及的 SQL 子集也没有单独规范。与会者同意把 Web SQL Database 改发为工作组说明。有人说将来若有兴趣可以重启，另有人提醒重走推荐标准程序还得重新处理知识产权流程。保留文档，和宣布它成为标准，是两件事。

11 月 18 日发布的工作组说明在状态栏写明：推荐标准轨道上的工作已停，需要多个独立实现。可在正文的 SQL 一节，读到用户代理应实现 SQLite 3.6.19 所支持方言的要求。版本号都成了语言定义的一部分。W3C 同时继续 Web Storage 与 IndexedDB；其 2011 年 8 月技术概览将浏览器端 SQL 数据库工作称为已放弃，改由 IndexedDB 方向承接。

这份记录不能告诉我们哪天每款浏览器移除了 Web SQL，也没有网站依赖数量。要回答部署后果，需逐版本浏览器与应用使用记录。它已经说明另一件更具体的事：两份产品实现若共享一台发动机，仍不足以证明第三个人拿着图纸就能造出同样的车。

原始记录