The problem of having the standard defined by an implementation is that it makes it almost impossible to have another implementation.
This is fine if we agree here and now in 2013 that WebKit is the only rendering engine we'll ever need.
That just doesn't seem like a smart bet to make. Opera was in some ways better than the WebKit browsers on mobile devices, except for broken Webkit only sites. That ain't going to get better now.
It's even worse. You're letting the standard be defined by a specific version of an implementation. It would impede progress for future versions of the same implementation.
For example today I just browsed my Internet provider's customer area. Their online invoicing page only works on Firefox and IE7, but not IE8, IE9, Opera and Chrome. Urgh.
> That just doesn't seem like a smart bet to make. Opera was in some ways better than the WebKit browsers on mobile devices, except for broken Webkit only sites. That ain't going to get better now.
But a de facto standard (ie one defined by a popular implementation) forces sites to be compatible or be ignored. More monolithic standard => stronger coding conventions => more robust web. Or am I being totally idealistic?
Robustness does not come from more rigid standards. For instance, it doesn't matter how standardized JavaScript is, it will still be a bad language in so many ways. If anything, standardization locks in the bad feature set, making is far harder to remove or fix.
Robustness often comes from the opposite approach. It's the willingness to throw out ideas and code that are observed to be broken. Replacing JavaScript with a more sensible scripting language like Lua or Python would increase the robustness of the web, while standardizing it further only entrenches the problem deeper.
A lot. The problems should be quite apparent to any developer who has used any mainstream programming languages aside from JavaScript and PHP. But for those who don't have such experience, a few quick Google searches should turn up more than enough information indicating the problems with JavaScript. There's no need to rehash it here.
No, it's not quite apparent at all, and no, a few Google searches did not yield any useful information. (I do however like the high horse you're on, very nice breed indeed.)
I call on your "no need to rehash it here." Without even one good example, I'd say you're just trying to be elitist.
I'm sorry to hear that you've had so much trouble with this very simple exercise.
Let me help set you on the right path. Google for "javascript semicolon insertion". After reading about it, it should be very apparent to you how it's a very large flaw with the language, and how it can be extremely harmful.
Do some research into JavaScript's equality operators. Any good programmer will be sick to his or her stomach after reading about how broken such basic, yet essential, functionality like that is.
And that's just the start, my friend. I encourage you to do further research on your own. You'll find no shortage of serious issues to learn more about.
But a de facto standard (ie one defined by a popular implementation) forces sites to be compatible or be ignored.
No, it's totally the opposite. They only have to be "compatible" with this one implementation, and are free to rely on all implementation-specific bugs or implementation defined behavior when doing so.
Think IE box model around the IE5/6 age. Or hell, supporting Office Documents. Even if you'd have the source, being compatible certainly wouldn't have gotten much easier.
Note that WebKit is open source and Opera is having problems being bug-compatible with it.
Indeed - in principle. But that was back when MS handed down IE binaries from the mountaintop whenever it wanted and most people ran different proprietary OSes. WebKit is open source and it runs on every major platform.
Although there is a chance here for the -prefix-rabbit-hole to yawn wide, there's also an opportunity for a (nearly-)universally-supported rendering engine to emerge that could, one day, get into bed with the standards committee. Surely this would be a good endgame for the browser wars?
The only worry here, as always, is that an implementation will come to define the standard rather than the other way around.
Note that coding to an implementation rather than a standard does stifle innovation, because when you code to target the implementation you inevitably rely on bugs in the implementation, without ever knowing or trying to. From the perspective of an implementor, would you fix a bug even if it meant breaking an unknowably large number of websites? If not, you've adopted that bug for the rest of time, and every subsequent implementation, ever, will be forced to implement the bug as well when they could be busy implementing new features. Now compound this by thousands of bugs, and reflect on all the time spent implementing Quirks Mode in every browser engine that exists today.
I do agree with you that in a perfect world we wouldn't need multiple implementations, because bugs would not exist and the lone implementation would track the standard perfectly, and because the standard would be controlled by neutral third-parties. But I think it's much too soon to declare the current era the browser endgame.
This is fine if we agree here and now in 2013 that WebKit is the only rendering engine we'll ever need.
That just doesn't seem like a smart bet to make. Opera was in some ways better than the WebKit browsers on mobile devices, except for broken Webkit only sites. That ain't going to get better now.