Hacker News Reader

Comment by ekianjo | Hacker News Reader

Flash was never a web standard. XLST is.

What's the practical different to users and site maintainers?

Flash was dependent on a proprietary plugin from a single vendor. XSLT styled documents are compatible out of the box in any web browser from multiple competing vendors, even old Internet Explorer.

The iPhone never supported Flash. But thanks to web standards it supports viewing RSS feeds and other weird XML/XSLT artifacts from the past to this day.

Maybe I'm missing something here, but can't XSLT be processed server side instead of browser side?

It seems like a very easy fix for the handful of websites that still use it.

There are no easy fixes for government sites.

RSS/Atom feeds can use them. How does it make sense to maintain two versions of the same data on the server?

Exactly. The Atom feed of my website declares an XSLT stylesheet which transforms it to HTML. That way it can be served directly to, and renders prettily by, a web browser (see https://paul.fragara.com/feed.xml). For the curious, the XLST can be found here: https://gitlab.com/PaulCapron/paul.fragara.com/-/blob/master...

Btw, you can also apply an XSLT sheet to an XML document using standard JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcess...

There would be no reason to fix this if the chrome people had kept up their end of the bargain by supporting the standard. We can quibble as to whether or not XSLT should have been part of the standard to begin with but it IS part of the standard.

Google says it's "too difficult" and "resource intensive" to maintain...but they've deliberately left that part of the browser to rot instead of incrementally upgrading it to a modern XSLT standard as new revisions were released so it seems like a problem of their own making.

Given their penchant for user-hostile decisions it's hard to give the chrome team the benefit of the doubt here that this is being done purely for maintainability and for better security (especially given their proposal of just offloading it to a js polyfill).

Commercial enterprises can only support standards if it's commercially viable.

It's commercially beneficial to make the web standard so complex that it's more or less impossible to implement, since it lets you monopolise the browser market. However complexity only protects incumbents if you can persuade enough people to use the overcomplicated bits. If hardly anyone uses it, like xslt, then it's a cost for the incumbent which new entrants might get away without paying. So there's no real upside for Google in supporting it. And you can't expect commercial enterprises to do something without any upside.

I expect commercial enterprises not to be allowed to engage in anti-competitive and consumer-hostile behavior. Like it or not and regardless of their contributions to tech/the web Google is notorious for pulling the rug out from under open industry standards only to replace them with their own proprietary or, as you described, "standards" that are so complex it's more or less impossible to implement so you're "forced" to use/buy their product.

They will be as anti-competitive and as consumer hostile as they can get away with. Adding and removing features from the standard is so ambiguously motivated that I almost can't imagine them being successfully prosecuted for it. In a way it's pretty clever.

Nobody is going to do things you agree with all the time. That doesn't mean everything they do should be condemned by default, without thorough investigation into their motives.

XSLT is often used on low-power IOT devices which don't have the resources to render server-side

What are those low-power devices (can you identify any?) doing with XSLT, then? If they don't have the power to do the transformation, it seems pointless for them to possess the template needed to perform the process.

that's why they use XSLT. the whole point is that rendering happens in on the client.

you can find discussion in the several other recent XSLT threads

XSLT is by and large single-threaded, and most jobs in the print domain get horrifyingly ginormous due to basic conceptual flaws of XML/XSL. Your Operations guys might have a panic attack when they see how that impacts on the server side. But then, to mitigate that, someone's going to need to cook a queueing system with some kind of notification/email doohickey, and now the InfoSec guys are also having a panic attack.

You're probably going to save money, end of the day, just homebrewing some XSL drop ins with a real programming language.

I gotta say, as a mostly-defense XSL guy[1] who also knows his way around TS and Py, this is probably going to be a real boom time to kick this dumb XSLT work to the curb and do some high dollar contracting making JS/TS drop-ins for govcons and defense.

[1] Who also thinks XSLT is a joke told by an idiot. My morale? Oh, it's great.

Reply on news.ycombinator.com