5 ms·

> you don't need to talk about pointer events or flexbox or indexeddb or whatever But missing functionality is a deal breaker. * WebRTC - web peer to peer con

• bad_user 12y ago
  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.
  • frik 12y ago
    * 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 https://news.ycombinator.com/item?id=9082847
    • thristian 12y ago
      > 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.
      • frik 12y ago
        * There is a common misconception about SQLite3 dynamic type system. It can be done using SQL statements: http://stackoverflow.com/a/2762020 http://stackoverflow.com/a/2762020, http://www.sqlite.org/datatype3.html 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 http://en.wikipedia.org/wiki/SQL-92 * Beside that even if Microsoft would use JetRed (http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine) or JetBlue (http://en.wikipedia.org/wiki/Microsoft_JET_Blue 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.
        • dragonwriter 12y ago
          > 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.
  • saidajigumi 12y ago
    > 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.
    • azakai 12y ago
      SQLite is kind of different from other DBs, in various ways. For example, data types, http://www.sqlite.org/datatype3.html 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.
• Tloewald 12y ago
  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).
  • frik 12y ago
    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.
    • Tloewald 12y ago
      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.
  • jqm 12y ago
    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.