Comment by shadowgovt

3 months ago

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.

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?

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