Live data from Hacker News

Google did not unilaterally decide to kill XSLT

meyerweb.com

131–138 of 138 posts

Re: Google did not unilaterally decide to kill XSLT

#131
post #41

Earlier quoted context omitted.

XSLT in the browser was always a bad idea.

What? XSLT in the browser is an awesome idea. It let web sites publish data unencumbered by presentation and let the client's user agent decide how to use the data. Your browser can download the XML and use a linked XSL stylesheet to display it for a graphical browser. That exact same data resource could be used instead by a program that understands the schema of the data and do some custom thing with it. There's no…

The reason it is a bad idea is because XML, XSLT and related standards are almost impossible to implement. I don't think there is any non-broken implementation of it. The idea behind it is interesting but the actual standards and libraries involved are awful.

Re: Google did not unilaterally decide to kill XSLT

#132
post #36

Earlier quoted context omitted.

XSLT specifics? Yes, ubernerd ... Person who can't get a doctor's appointment because the interactive voice menu which is somehow now based on a browser engine and has a subtle bug caused by this change could be anyone.

Is there some specific reason you think xslt removal is likely to cause this (because it is used in interactive voice menus)? Or is your complaint here reducible to "changes in browsers can cause bugs, and bugs can harm consumers" for which the solution is "browsers must never change anything", which is of course also harmful to consumers (like when an xslt parser bug is used to steal my bank details)

I have personally witnessed web technology related components in the critical path of complex enterprise insurance systems. Setting aside things like the whole of .NET being steeped in web browser components, and the added complexity of being forced to isolated these components by the court, things like Selenium are used for getting around integration and licensing problems. It isn't right, it isn't efficient, it will be a year long project to change them... We've already seen outages caused by XML engines dereferencing domains that aren't available anymore causing subtle and hard to find bugs. People don't realize that we built a lot of cool stuff on XML and semantic web stuff that all works and is all needed in various ways! It would not surprise me if web browser automation is not central to a ton of backend integration and automation for absolute sure.

Re: Google did not unilaterally decide to kill XSLT

#133
post #101

Earlier quoted context omitted.

You can certainly use XSLT with https://www.w3.org/TR/voicexml20/ have you built software on any Linux platform? XSLT is required in so much stuff.

And did you render it in chrome? Nobody is killing xslt in general, just the web browser bindings.

I mentioned it elsewhere but tons of enterprise backend automation and integration has web browsers and web browser components in the critical path, yes.

Re: Google did not unilaterally decide to kill XSLT

#134
post #132

Earlier quoted context omitted.

Is there some specific reason you think xslt removal is likely to cause this (because it is used in interactive voice menus)? Or is your complaint here reducible to "changes in browsers can cause bugs, and bugs can harm consumers" for which the solution is "browsers must never change anything", which is of course also harmful to consumers (like when an xslt parser bug is used to steal my bank details)

I have personally witnessed web technology related components in the critical path of complex enterprise insurance systems. Setting aside things like the whole of .NET being steeped in web browser components, and the added complexity of being forced to isolated these components by the court, things like Selenium are used for getting around integration and licensing problems. It isn't right, it isn't efficient, it wil…

You understand that XSLT isn't xml, right? This change will probably have a 0% impact on selenium or similar browser automation.

Re: Google did not unilaterally decide to kill XSLT

#135
post #132

Earlier quoted context omitted.

I have personally witnessed web technology related components in the critical path of complex enterprise insurance systems. Setting aside things like the whole of .NET being steeped in web browser components, and the added complexity of being forced to isolated these components by the court, things like Selenium are used for getting around integration and licensing problems. It isn't right, it isn't efficient, it wil…

You understand that XSLT isn't xml, right? This change will probably have a 0% impact on selenium or similar browser automation.

> You understand that XSLT isn't xml, right?

XSLT is XML, but XML isn't XSLT.

Re: Google did not unilaterally decide to kill XSLT

#136

Earlier quoted context omitted.

You understand that XSLT isn't xml, right? This change will probably have a 0% impact on selenium or similar browser automation.

> You understand that XSLT isn't xml, right? XSLT is XML, but XML isn't XSLT.

Well they meant that I was conflating two things, and I was, because you can reference stylesheets to transform XML from one form to another, you can use it to render XML into HTML (or anything within limits), and that was the part that I was referring to specifically. That process can happen in a browser, on the command line, inside of Java dependency injection, build systems... It's in a lot of things because for what it is and what it can do it is pretty broadly applicable. It just isn't sexy front end or clear isolated backend so maybe that's the confusion here. I'm talking IBM, Oracle software acquired over decades from smaller companies that tried it all. And taking it out of a browser engine breaks these systems as well. A browser is used for testing, literal hack glue using tools like Selenium for systems integration, end users interacting with the system or administrators interacting with them... And again, some systems use browsers programmatically... XSLT is huge in mid 2000s report generation. The more I think about it, it does feel like a mini Y2K to touch the HTML rendering pipeline in this way. I think it could have subtle and hard to find consequences, and it doesn't feel extreme, maybe making a whole thread does about it though lol

Re: Google did not unilaterally decide to kill XSLT

#137

Earlier quoted context omitted.

Removing Flash, Mutation Events, and third-party cookies broke websites.

Look man, Flash was not the same thing and people need to stop bringing this up. Flash was a third party plugin that got way out of hand. It wasn’t (necessarily) the job the browser vendors created for themselves and offered for years . Flash was also moreso removed on a fledgling platform first that grew to be a dominant platform; it wasn’t killed off on an existing dominant platform first .

You've completely disregarded the other examples of breaking changes that have already been made. The open web still survives afterwards. The web isn't immutable no matter how much people might want it to be.

Re: Google did not unilaterally decide to kill XSLT

#138

Earlier quoted context omitted.

Look man, Flash was not the same thing and people need to stop bringing this up. Flash was a third party plugin that got way out of hand. It wasn’t (necessarily) the job the browser vendors created for themselves and offered for years . Flash was also moreso removed on a fledgling platform first that grew to be a dominant platform; it wasn’t killed off on an existing dominant platform first .

You've completely disregarded the other examples of breaking changes that have already been made. The open web still survives afterwards. The web isn't immutable no matter how much people might want it to be.

No, I didn't. Did you even read my comment?

I called out Flash. I could not have written a more straightforward note about how their comment was set up. Nothing I said indicated I disagree with their overall stance, just that Flash is a ridiculous thing to trot out.

Post reply on HN