I believe you, but I think I missed that part of the conversation.
Running an XSLT engine in JavaScript is sandboxed. It's sandboxed by the JS rules. In terms of security, it's consolidating sandboxing concerns because risk of breaking XSLT becomes risk of breaking the JS engine, whereas right now there are two potential attack vectors to monitor.
(There is an unwritten assumption here: "But I can avoid the JS issues by turning off JavaScript." Which is true, but I think the ship is pretty well sailed for any w3c-compliant browser to be supporting JavaScript-off as a first-class use case these days. From a safety standpoint, we even have situations where there are security breach detections against things like iframe-busting that only work with JavaScript on).
The question for all the browser developers is not “can we feasibly support this feature” but “is it worth it to support this feature”?
Because they must address the security problems, there is no zero-cost solution to maintain compatibility. They either abandon it or rewrite it which comes with support costs forever.
I understand you believe they made the wrong choice and I understand why you feel that way. But according to their calculus they are making the right choice based on how widely used the feature actually is.
I believe you, but I think I missed that part of the conversation.
Running an XSLT engine in JavaScript is sandboxed. It's sandboxed by the JS rules. In terms of security, it's consolidating sandboxing concerns because risk of breaking XSLT becomes risk of breaking the JS engine, whereas right now there are two potential attack vectors to monitor.
(There is an unwritten assumption here: "But I can avoid the JS issues by turning off JavaScript." Which is true, but I think the ship is pretty well sailed for any w3c-compliant browser to be supporting JavaScript-off as a first-class use case these days. From a safety standpoint, we even have situations where there are security breach detections against things like iframe-busting that only work with JavaScript on).
The question for all the browser developers is not “can we feasibly support this feature” but “is it worth it to support this feature”?
Because they must address the security problems, there is no zero-cost solution to maintain compatibility. They either abandon it or rewrite it which comes with support costs forever.
I understand you believe they made the wrong choice and I understand why you feel that way. But according to their calculus they are making the right choice based on how widely used the feature actually is.