XHTML2 was dead on arrival. Mozilla didn't do anything to sabotage it; it sabotaged itself by completely dropping backwards compat in such a horrible way that you could only implement XHTML2 or something that would render existing websites, but not both, unless you jumped through some pretty ridiculous hoops. It turned out, no one wanted to jump.
Plugins were killed by most browser vendors more or less at once, and Mozilla wasn't even the first one.
Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl.
WebSQL is the one thing that I am aware of that Mozilla in fact opposed when others were broadly in favor, but the reason was not NIH. It would have been pretty simple to implement WebSQL in Gecko. The opposition came down to two things, I believe. The first was a simple observation: the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL; the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite. There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell. The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in). I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me.
[Disclaimer: I work for Mozilla, and did back when most of the things you mention were being discussed, but was not actively involved in the WebSQL/IndexedDB discussions.]
> Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl.
Heck, Dart was opposed by the Chrome team: there's a reason why it never made it into Blink. NaCl is slightly different insofar as the Chrome team didn't actively fight it.
XHTML was not "dead on arrival"; that is some seriously fabricated FUD. XHTML came at a time when it was entirely positioned to take over as the proper way of doing things. It had its own mime type to differentiate itself from HTML, in order to allow older content to continue to be served as soup during a deprecation phase. The demand for this strictly validatable syntax was incredible; it was absolutely in a place where it should (not could) have become the new standard.
It wasn't us web developers who rejected the call to action. We were begging the other vendors to add support for the XHTML mime type. I spent two years of my career preparing for the transition that never came. We were at the point where we served a different mime type depending on the requesting user agent, having refactored everything to return perfectly compliant XHTML responses. That is how seriously the industry anticipated the changeover.
It was the browser vendors who turned a blind eye. The childish browser wars, throughout which each company refused to cooperate with the competition out of self-interest to hoard the market, mutilated the web. Had the vendors all agreed to support XHTML within a span of 6 months, today we would have 100% well-formed XHTML. Instead, browsers still parse meaning out of LITERAL GARBAGE. HTML soup is so pathetic that there are no words to describe it.
Please show me a programming or scripting language that allows you to write code with syntax errors, whereby the compiler or interpreter never throws an error, instead taking a best guess stab at what you meant to code. It doesn't exist, because... SURPRISE - the level of absurdity required to permit such a thing is unfathomable. And yet that is exactly what we have with html5.
Aside: what the actual fuck is up with CDATA elements still being required to be CDATA. The fact you have to write <script src="/main.js"></script> instead of <script src="/main.js"/> is the only thing someone needs to know in order to understand the disgusting origins of the "modern" web.
> XHTML was not "dead on arrival"; that is some seriously fabricated FUD
Are you talking about XHTML in general, or XHTML 2 specifically? They're not the same thing. I was talking about XHTML 2 specifically.
> It had its own mime type to differentiate itself from HTML
XHTML 2 did not have its own MIME type to differentiate itself from XHTML 1. This was precisely the problem, because it used the same MIME type, same namespace, and same localnames to mean different things from XHTML 1.
> today we would have 100% well-formed XHTML.
We can have a long discussion about XHTML 1 and whether it would have seen better uptake with better support. I will only note that all browsers support XHTML 1, with the XML serialization, and have for years. And similar for HTML5 with its XML serialization. Yet neither one has any uptake...
I should also note that your "browser vendors" lumping-in is a bit weird. The only browser vendor that did not support XHTML was IE (admittedly a large fraction of the market, which made deploying XHTML hard). But you make it sound like there was some conspiracy of browser vendors to ignore XHTML, when in reality all of them except Microsoft implemented it fairly quickly.
> The fact you have to write <script src="/main.js"></script> instead of <script src="/main.js"/>
You don't. <script /> is valid, but in XHTML. If you don't get the mimetype right, and the browser isn't parsing you as XHTML, it won't work.[1] In HTML5, self-closing tags are only valid in particular contexts, and this isn't one of them.[2] (Really, for the HTML tags, you can pretend that self-closing doesn't exist in HTML5, so no <script />. Since script sometimes has content, it needs a closer, so </script>. I do find it as annoying as I suspect you do, however.)
The point I was making is that nobody uses XHTML thanks to the browser vendors' refusal to accommodate it early on when the demand was rampant. By the time the comparison was html5 vs. XHTML2 instead of HTML 4 vs XHTML1, it was too late as we had been trained to ignore the XHTML variant due to the vendors' absolute refusal to even make XHTML1 work. If you know of a single major site (not somebody's little side project) that uses the XHTML mime type, please share so I can be amazed.
The fact that the html5 spec does not permit self-closing CDATA elements is precisely the kind of legacy trash we'll be dealing with for yet another 10-30 years. (I understand that html5 didn't change the parsing rules from HTML 4 in order to be backwards-compatible, but it's still infuriating).
> The point I was making is that nobody uses XHTML
I don't disagree here.
> The fact that the html5 spec does not permit self-closing CDATA elements
The HTML spec does permit self-closing <script>: in the XHTML syntax.
The HTML5 specification defines two "concrete syntaxes" for HTML: HTML, and XHTML. The latter supports self-closing <script> tags perfectly fine.
The former (the HTML syntax), only allows self-closing tags in two contexts: void tags (of which <script> is not), and foreign tags (e.g., SVG, and XML-like stuff). Now, perhaps you can argue that they should just have allowed it on all elements, such as <script>; frankly, I feel like the reason the standard permits it on void elements at all is just to handle the legions of webdevs out there who think they're writing XHTML but only ever use the syntax for <br/> and are incorrectly serving the resulting soup with text/html.
But, if you're writing the HTML syntax, just write the HTML syntax. Some elements require the end tag, some don't. Typically, it is simple enough to tell, simply by asking "could this element have content?" (if yes: end tag, else: no end tag) If you want more consistent parsing rules, that's what the XHTML syntax is for. (Though I agree, it doesn't seem to see much real-world use.)
(Frankly, I greatly prefer the gentle fallback of the HTML syntax compared to the hard error of the XHTML syntax, which is considerably user unfriendly.)
> By the time the comparison was html5 vs. XHTML2 instead of HTML 4 vs XHTML1
The relevant comparison is html5 in its HTML serialization vs html5 in its XML serialization. The latter works in every single browser, and has since IE9 shipped in 2011. No one uses it.
> If you know of a single major site (not somebody's little side project) that uses the XHTML mime type
There aren't any, because I suspect people building such sites all discovered the same thing: ensuring well-formedness is _hard_ in practice, and if it's required for the page to be shown at all, then your page will fail to be shown every so often. And no one wants to deal with that.
Back when some people were in fact trying to use XHTML on the web, every so often you'd run into this on some site that sent XHTML based on "Accept" headers. You'd load the site in Mozilla (suite, then Firefox when it came into being) and get an XML parsing error.
There were two common sources of this problem. First, someone editing a template and forgetting to modify closing tags to match opening ones. This can be solved with server-side enforcement of template well-formedness, of course. But it means you can't have your start and end tags in different parts of the template or different templates, which people wanted to do.
Second, insertion of content you don't control, whether it's user-contributed, or coming from some other team (e.g. content-production team on a news site feeding their bits into the CMS templates), or coming via a content provider like the AP or whatnot. You can mitigate this by using a fully DOM-based workflow, serializing before you put on the wire, instead of pasting together strings. But now you have the problem of producing a DOM from whatever non-well-formed garbage you were handed. Yes, you can just reject non-well-formed input, but if you have no leverage over the producer of that input, that just means you can't do your job. OK, so maybe you have a more liberal parser on the input end and then ensure everything internally operates on trees, not text.
But the upshot in the end is that you end up with a lot more effort and the benefits are not entirely obvious (at least not entirely obvious to your management; there are certainly obvious anti-XSS benefits to having good control of what tokens end up in your output and where escaping happens, etc). So the path of least resistance is to just not go there in terms of the XHTML serialization of HTML.
> The fact that the html5 spec does not permit self-closing CDATA elements
I'm not sure why "CDATA element" is important here. You'd want self-closing <style> and <script> but not self-closing anything else? The idea doesn't even make sense for <style>, so presumably you just want self-closing <script>?
>>>the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL
This is a convincing argument that's a stupid rule, not a convincing argument against WebSQL. Standardization processes are and ought to be a means, not an end in themselves.
If standards body rules are blocking progress on new features which are eagerly anticipated by developers and significantly improve the experience for users, that means the rules are broken. Standards bodies work for the community, not the other way around.
Also, this particular bit of standards-lawyering was a blatantly-hypocritical dodge. Virtually every web technology was first implemented in one browser before it was in others.
This is an all-purpose, substance-free objection that could've been, and can be in the future, made against any significant web technology, including those promoted by Mozilla.
Also, every browser, including Firefox, implements IndexedDB with ... sqlite.
One of Mozilla's actual arguments was "we surveyed front-end webdevs, and they said 'ZOMG, SQL isn't webscale!! XD'" Apparently browser development is to proceed on the Idiocracy principle.
But leaving that aside, Apple and Google did their own surveys and found that developers (who had actually used or knew of WebSQL) were overwhelmingly positive. Whereas impressions of IndexedDB are overwhelmingly negative, especially vis-a-vis WebSQL.
To this day, 7 years after its deprecation, and still never having been implemented in a Microsoft or Mozilla browser, developers have voted with their feet for WebSQL; it remains far more frequently used than IndexedDB.
Even as a cross-browser solution, the default remains LocalStorage while IndexedDB languishes in much-deserved obscurity.
>>>the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite.
Good thing then that sqlite is one of the most mature and stablest programs in existence. sqlite's query API has broken backwards compatibility less in 17 years than most any web API does in 5. It wouldn't even be particularly burdensome to track sqlite in near-real-time.
Implausible worst-case scenario, you have to fork sqlite at a specific version. sqlite currently has 3 part-time maintainers.[1] The costs associated with maintaining a fork would be a pittance for an organization Mozilla's size.
Also, sqlite is free software, unencumbered by patents — there's absolutely nothing preventing anyone from making their own independent reimplementation of sqlite, it's just that there's no reason to because the original implementation is comprehensively battle-tested and of excellent quality by any metric.
sqlite is so good that, forget about sqlite's dialect, nobody feels the need to develop a competitor in its niche of embedded RDBMS, period. This is an excellent reason for using sqlite, not against.
>>>There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell.
I'd have preferred an ActiveRecord-style API, which in addition to being more ergonomic also would've been independent of a specific backend, but you can't let the perfect be the enemy of the good. Or abandon both perfect and good in favor of unusable garbage.
>>>The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in).
This is incorrect, WebSQL's API is entirely async. But even if it weren't it wouldn't matter because it's blazing fast, around 50x faster than IndexedDB and as often as not it's the Javascript engine that struggles to keep up rather than the reverse.
>>>I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me.
That's one of the less colorful ways of putting it, yes.
This one's getting quite long so I'll address your other points in a separate reply.
There's a good reason for the two-implementations rule: it's to make sure the standard is sufficiently clear to be actually implementable.
> Also, every browser, including Firefox, implements IndexedDB with ... sqlite.
But abstracted away. And, importantly, not tied to a particular version. So if there's a security bug in sqlite (yes, I know, rare), you can just fix it without changing the web-exposed behavior in any way, for example.
I understand that you like sqlite. But it's not clear that having a web standard that says "yeah, just ship sqlite" is the right thing. For one thing, that requires you to ship code in a particular language (C). That's usually something standards try to avoid.
Plugins were killed by most browser vendors more or less at once, and Mozilla wasn't even the first one.
Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl.
WebSQL is the one thing that I am aware of that Mozilla in fact opposed when others were broadly in favor, but the reason was not NIH. It would have been pretty simple to implement WebSQL in Gecko. The opposition came down to two things, I believe. The first was a simple observation: the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL; the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite. There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell. The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in). I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me.
[Disclaimer: I work for Mozilla, and did back when most of the things you mention were being discussed, but was not actively involved in the WebSQL/IndexedDB discussions.]