Standards are for platform implementors. Developers inevitably ignore standards, and instead code "empirically" to whatever the implementation they're developin

Standards are for platform implementors. Developers inevitably ignore standards, and instead code "empirically" to whatever the implementation they're developing against is willing to expose—both in terms of features (guaranteed by the standard or not), and in terms of bugs. (Yes, those devs are doing a bad thing. They should only obey the letter of the standard, and not "look through" to what the implementation is doing. But we can't just intentionally break support for the stuff they build through this empirical-discovery-of-features-and-bugs process. That would just hurt the innocent users who just want to access their websites — which might very well be abandonware by the point that we discover and fix whatever standard-nonconformance bug such sites relied upon.) What we can do to control developer behavior, is to impose incentives. If there are multiple implementations of the standard in popular use in different browsers, each with different bugs, then developers will feel the need to support those different browsers, and so will test in them, find where the deviations from the standard cause breakage, and so end up coding portably. But if all the implementations in use in different browsers have the same bugs (perhaps because they're all actually the same implementation), then even supporting multiple browsers won't do anything to break people's assumption on those bugs; and so people will write brittle code that depends on exactly those bugs being present to work, and will break even if the platform implementor just upgrades the implementation to a newer version without the bug. This is the "bug-for-bug compatibility" that Microsoft worries so much about across Windows versions. It's a royal PITA to support, and W3C/WHATWG/etc have thusfar assiduously avoided allowing anything into the standards which has only one implementation, and therefore which devs could ever "lock onto" the bugs of with brittle implementations. --- Also, this ignores that most of the "pragmatics" of managing a SQL DBMS are not specified by the SQL standard. SQL is not as standard as people think it is! ANSI SQL is mostly concerned with specifying how DML queries work; the DDL stuff is almost entirely a mess of implementation-defined syntax that happens to share some conventions, but with no standards guarantees. Check this out: https://www.postgresql.org/docs/current/sql-createindex.html#id-1.9.3.69.9 https://www.postgresql.org/docs/current/sql-createindex.html... > CREATE INDEX is a PostgreSQL language extension. There are no provisions for indexes in the SQL standard. Do you really want to expose a SQL API where you can't create indices, because there's no portable syntax for creating indices? Would such an API even be useful? If we really wanted a "web SQL API", the designers of said API couldn't just lean on the existing SQL standard; they would actually have to standardize what "web SQL" syntax is themselves — probably as a superset of ANSI SQL, but still laying out a bunch of additional requirements. It'd be similar in scope to WebGL. That's a big ask. And even if they did that, that'd likely mean that they'd end up with no existing implementations of the standard! (Because it's not like you'd want to lock in all of SQLite's nonstandard DDL syntax choices as "the" WebSQL syntax, right? You'd want to think these out "from first principles", considering what's most "implementation-neutral.")