[righthand]

Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use.

Not: popular browsers needle through technologies and tell everyone they know best

Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using.

What is open web to you? “Overpaid Mba at Google says this is best so you better fall in line.”

[dpark]

> Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use.

The “wide range of technologies” is not what makes the web “open”.

The openness comes from the fact that anyone can write web sites and anyone can write a browser that can render the same websites that chrome can render. “More features” does not imply “more open”.

Dropping support for xslt would make the web less open if it were being replaced by some proprietary Google tech. But that’s not what’s happening here at all.

> Not: popular browsers needle through technologies and tell everyone they know best

How else would it possibly work? Everyone has to actively choose the features they will build and support.

[righthand]

I don’t care to continue this discussion primarily because you are making nearly the same points as two other commenters and it has become a three way exhausting conversation. You hate XSLT or something and love Google, congrats, you win this discussion. XSLT will be removed, Javascript will reign king. You will be happy. Every one will say Mason Freed is right and smart and that XML sucks because no one who matters uses it. I was never going to convince you to like or consider other technologies, anyways. And since that is true, this conversation doesn't do anything to try and help save XSLT and not worth continuing for me at least.

I wish it weren't the case but good luck and I'm sure we'll speak again with nearly the same conversation at the next thread for a standard deprecation that ad companies don't like.

[shadowgovt]

Bold of you to assume other commenters in this thread have no experience with XML or XSLT.

I was there when it was the new hottest thing and I was there when it became last year's thing. These things come and go, and this one's time has come.

[shadowgovt]

Given that the thing we want to support can be supported via server-side translation, client-side translation in JavaScript, or automatic detection and translation via a third-party plugin in JavaScript... What bearing on the open web does it have to preserve this functionality as a JavaScript-accessible API built into the browser?

I don't see how removing this API harms the open web. I do see how it imposes some nonzero cost on website maintainers to adapt to the removal of the API, and I respect that cost is nonzero.

... but I also watched OpenGL evolve into OpenGL ES and the end result was a far better API than we started with.

I don't think XSLTProcessor joining document.defaultCharset in the history books is damage to the open web.

ETA: And not that it matters over-much, but the "overpaid Mba" is an electrical engineering Ph.D who came to software via sensor manufacturing, so if you're going to attempt to insult someone's training, maybe get it right? Not that he'd be wrong if he were an Mba either, mind.

[righthand]

No the Mba is Freeds boss who installed him there and ensure he enforces closing of the web. Coming from sensor manufacturing to software isn’t really that impressive but it does make sense why a sensor manufacturing engineer would make arguments for removing a spec like XSLT but not a terribly complicated and security vulnerable spec like bluetooth. Which probably has 10x the complexity and 10x security plane of xslt. Thank you this whole thing is an even bigger joke.

Enjoy the precedent this sets for other tech not in the Google stable. You clearly are getting what you want so why continue this discussion. Who are you trying to convince?

[shadowgovt]

> Which probably has 10x the complexity and 10x security plane

... and 10x the utility, since unlike XSLT Bluetooth requires sandboxed and mediated access to OS-level APIs that cannot be feature-compatible replicated with 3MB of JavaScript.

[righthand]

And sandboxing Xslt was one of the suggested ways to not break the web. But they ignored it.

[shadowgovt]

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).

[dpark]

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.