One of the things that startled me when working for Google is how much of their decisionmaking actually looks like "This sucks and we don't want to be responsible for it... But there isn't anyone else who can be, so I guess it's us."
I'm not saying this is optimal or that it should be the way it is, but I am saying there are problems with alternative approaches that need to be addressed.
To give a comparison: OpenGL tried a collaborative and semi-open approach to governance for years, and what happened was they got more-or-less curb-stomped by DirectX, so much so that it drove Windows adoption for years as "the architecture for playing videogames." The mechanism was simple: while OpenGL's committee tried to find common ground among disparate teams with disparate needs, Microsoft went
1) we control this standard; here are the requirements you must adhere to
2) we control the "DirectX" trademark, if you fail to adhere to the standards we decertify your product.
As a result, you could buy a card with "DirectX" stamped on it, slap it into your Windows machine, and it would work. You couldn't do anything like that with OpenGL hardware; the standard was so loose (and enforcement so nonexistant) that companies could, via the "gestalt" feature-detection layer, claim a feature was supported if they had polyfilled a CPU-side software renderer for it. Useless for games (or basically any practical application), but who's gonna stop them from lying?
Browsers aren't immune to market forces; a standard that is too inflexible or fails to reflect the actual implementation pressures and user needs will be undercut by alternative approaches.
I'm not saying current governance of the web is that bad, but I bring up the history of OpenGL as an example of why an open, cooperative approach can fail and the pitfalls to watch out for. In the case of this specific decision regarding XSLT, it appears from the outside looking in that the decision is being made in consensus by the three largest browser engine developers and maintainers. What voice is missing from that table, and who should speak for them?
(Quick side-note: Apple managed to dodge a lot of the OpenGL issues by owning the hardware stack and playing a similar card to Microsoft's with different carrots and sticks: "This is the kernel-level protocol you must implement in hardware. We will implement OpenGL in software. And if your stuff doesn't work we just won't sell laptops with your card in them; nobody in this ecosystem replaces their graphics hardware anyway").
Not suggesting an alternative model here, but I think that Google et. al (based on my own time working on Chrome) don't take that responsibility quite as seriously as they should. Being responsible may be an accident, but being dominant in any given area is not. The forces inside Google which take over parts of the world do so without really caring about the long term commitment.
It is so possible to preserve XSLT and other web features e.g. by wrapping them in built-in (potentially even standardized) polyfills, but that kind of work isn't incentivized over new features and big flashy refactors.
Completely agree. Among the reasons I no longer work for Google is that I could not escape the perception that they were the 800-lb gorilla in the room and deeply uncomfortable with taking on any responsibiliy given that circumstance.
When you are the biggest organization in a space, it's your space whether you feel qualified to lead or not. The right course of action is "get qualified, fast." The top-level leadership did not strike me as willing to shoulder that responsibility.
My personal preferred outcome to address the security concerns with XSLT would probably be to replace the native implementation with a JavaScript-sandboxed implementation in-browser. This wouldn't solve all issues (such an implementation would almost certainly be operating in a privileged state, so there would still be security concerns), but it would take all the "this library is living at a layer that does direct unchecked memory manipulation, with all the consequences therein" off the table. There is, still, a case to be made perhaps that if you're already doing that, the next logical step is to make the whole feature optional by jettisoning the sandboxed implementation into a JavaScript library.
One of the things that startled me when working for Google is how much of their decisionmaking actually looks like "This sucks and we don't want to be responsible for it... But there isn't anyone else who can be, so I guess it's us."
I'm not saying this is optimal or that it should be the way it is, but I am saying there are problems with alternative approaches that need to be addressed.
To give a comparison: OpenGL tried a collaborative and semi-open approach to governance for years, and what happened was they got more-or-less curb-stomped by DirectX, so much so that it drove Windows adoption for years as "the architecture for playing videogames." The mechanism was simple: while OpenGL's committee tried to find common ground among disparate teams with disparate needs, Microsoft went
1) we control this standard; here are the requirements you must adhere to
2) we control the "DirectX" trademark, if you fail to adhere to the standards we decertify your product.
As a result, you could buy a card with "DirectX" stamped on it, slap it into your Windows machine, and it would work. You couldn't do anything like that with OpenGL hardware; the standard was so loose (and enforcement so nonexistant) that companies could, via the "gestalt" feature-detection layer, claim a feature was supported if they had polyfilled a CPU-side software renderer for it. Useless for games (or basically any practical application), but who's gonna stop them from lying?
Browsers aren't immune to market forces; a standard that is too inflexible or fails to reflect the actual implementation pressures and user needs will be undercut by alternative approaches.
I'm not saying current governance of the web is that bad, but I bring up the history of OpenGL as an example of why an open, cooperative approach can fail and the pitfalls to watch out for. In the case of this specific decision regarding XSLT, it appears from the outside looking in that the decision is being made in consensus by the three largest browser engine developers and maintainers. What voice is missing from that table, and who should speak for them?
(Quick side-note: Apple managed to dodge a lot of the OpenGL issues by owning the hardware stack and playing a similar card to Microsoft's with different carrots and sticks: "This is the kernel-level protocol you must implement in hardware. We will implement OpenGL in software. And if your stuff doesn't work we just won't sell laptops with your card in them; nobody in this ecosystem replaces their graphics hardware anyway").