My point is that those technologies have been added to browsers, and we've been able to deal with the security surface.
Is merely repeating these past mistakes a high enough standard for a new technology? Particularly for one that would arguably be the worst of the lot? And for one that is getting a very late start in the arms race of exploit sophistication?
Is there not a suitable middle ground between <canvas> and OpenGL? An abstraction layer that is sufficiently powerful to not be the bottleneck, while permitting a secure implementation without the help of driver vendors and avoiding all the legacy cruft of OpenGL to boot?
First, it's not even close to being "worst of the lot".
Second, there might or might not be a middle ground, but you're not proposing it, Microsoft isn't proposing it and no one else is proposing it. In that context, bringing up non-existent, maybe-or-maybe-not better solution isn't advancing the discussion. In theory everything is possible but in practice WebGL implements a well understood model that has been in use for decades (just like canvas implemented a well understood model for 2D graphics). If we want fast 3D graphics in the browser, and we do, building on top of well understood technology is definitely the way to go (compared to trying to reinvent extremely complex technology that took years to perfect in the currently dominant standards (Direct3D and OpenGL)).
I disagree with the notion that it's OK to adopt a flawed standard just because no better proposal exists. A better proposal could most certainly exist if it was agreed that it should exist and resources were committed.
The OpenGL API has a ton of legacy baggage. Nearly all of GL 1.0 is deprecated and some parts of the API have endured multiple cycles of deprecation. Improving on it would not be difficult.
GLES is even cruftier than OpenGL, because they removed a bunch of functionality but didn't simplify the API. So you have all sorts of parameters and options that literally have no purpose. The documentation frequently says things like "The blah parameter controls yada yada. It's value must be zero." That's gotta be mighty confusing for a web developer doing 3D graphics for the first time.
The design of OpenGL is optimized for stateful, fixed pipeline, immediate mode drawing, an extinct paradigm that is unsupported in GLES and WebGL. The modern paradigm of shaders and GPU objects is radically different and demands an API tailored for it.
The continuity of OpenGL has been justified by its established ecosystem. Game developers prefered one patched up API to a new API for every generation of graphics hardware. But now hardware architecture has more or less stabilized and it's the developers that are new. Let's give them a fresh start instead of a badly mutilated API that, frankly, I think most of them will find impenetrable.
Is merely repeating these past mistakes a high enough standard for a new technology?
In a word, yes. Computing needs to be dragged kicking and screaming into the future of platform independence, and powerful 3D acceleration is an important component of a modern desktop system. The lessons learned in the previous rounds of new technology can be applied to mitigate some of the risks associated with WebGL.
Is merely repeating these past mistakes a high enough standard for a new technology? Particularly for one that would arguably be the worst of the lot? And for one that is getting a very late start in the arms race of exploit sophistication?
Is there not a suitable middle ground between <canvas> and OpenGL? An abstraction layer that is sufficiently powerful to not be the bottleneck, while permitting a secure implementation without the help of driver vendors and avoiding all the legacy cruft of OpenGL to boot?