Andreas
jwzThe World Wide Web Page https://xslt.rip is a thing of beauty on multiple levels. View source.
https://jwz.org/b/ykxK
https://jwz.org/b/ykxK
Dan Sugalski@jwz Oh, that is *glorious*! And awesome in its awfulness, I could make a good case that it's an excellent argument in favor of XSLT's death.
Mark T. Tomczak@jwz I like it as a work of art, but I 100% can't tell if the author is in favor of removing XSLT support from the browser or against it.
It's suffering from that Modest Proposal, Poe's Law problem: if I wanted to do a parody of the arguments for keeping it, I'd do it on a page that looks like it fell out of Geocities cache as a reminder that the web is really different from how it was when XSLT was adopted as a standard.
... even the "thoughts and prayers" is a meme that means "I don't actually care about this."
Oblomov@mark @jwz
If you want to see some more “serious” use XML+XSLT in action, I've been playing around with it for a while.
This page:
https://labrador.oblomov.eu/uberprufungslisten/
is XML+XSLT, as are the two subpages you can open by clicking on the two headers.
On my website https://wok.oblomov.eu/ I have plots that track my activity over time, with the SVG generated from XML+XSLT, details on the techniques are at
https://wok.oblomov.eu/tecnologia/plotting-xslt/
https://wok.oblomov.eu/tecnologia/plotting-sparklines-xslt/
and
https://wok.oblomov.eu/tecnologia/sparkling-wok-4/
as for the Google attack against XSLT, I have just published the second part of what I hope will be a long series (if not else because the longer it is the more we're on with XSLT):
The first part https://wok.oblomov.eu/tecnologia/google-killing-open-web/ contains a lot of historical background on Google's effort against the open web (of which the attacks on XML and XSLT are a nontrivial part); the second part has less history and more wishing:
https://wok.oblomov.eu/tecnologia/google-killing-open-web-2/
@oblomov @jwz I have a hard time accepting the story as simple as "Google wants to control the web" when Mozilla and Apple are apparently also on-board with jettisoning XSLT support in the browser.
To me, that smacks a lot more of "The browser vendors think this is one responsibility they can get away with shedding without the end user saying 'hey, the browser broke my favorite website'." And I don't really think the reasoning goes much beyond that; browsers are big hairy balls of code these days and any big subsection that can be shed I bet feels tantalizing to shed.
@oblomov @jwz What does "open" mean in this context?
This is one of the tricky bits of the whole argument I haven't been really able to wrap my head around.
"Open" can't mean as in "Possible to build an alternative browser to the Big Engines" in this context because if that were the goal, removal of something as complicated as XSLT in the feature spec would be a step in that direction, not away from it.
@oblomov @jwz Because we can implement XSLT in JavaScript but not the other way around. JavaScript has many, many, many issues, but it's a pretty good example of the "airplane rule" in terms of being the "one really good basket we keep all our eggs in" for security-sandbox purposes.
(Personally, I'd be 100% in favor of maintaining the XSLT APIs but under-the-hood implementing them in JavaScript, though that would still need security consideration since they'd likely be running in privileged context that has access to more state than regular in-page JavaScript. Possibly not necessary; I'm not familiar enough with the XSLT spec to guess off the top of my head).
I'm still struggling with what "open" means in this context, I'm afraid. Unless I've missed something really significant, this change wouldn't remove people's ability to use XSLT client-side if they wanted to; it would require a JavsScript polyfill (which, granted, will be a hell of a download first time... Alternatively, the XSLT could be pre-rendered to HTML server side and shipped down the wire).
if they can implement XSLT in JavaScript, why not just transition their implementation to a JS one, since the excuse they gave for removing XSLT is that the library they were relying on was old an insecure? Heck, they even wrote the JS polyfill, and are now asking everyone who uses XSLT to replace their correct markup to use XSLT with an invalid markup to use the JS polyfill they they need to ship themselves.
Because killing off XSLT and XML with it (RSS epsecially) is the point.
@oblomov @jwz I don't think this is a realistic way to attack RSS. Mostly because I don't really buy the narrative "Google killed RSS when they removed Reader." If all it takes to kill a protocol is shutting down one app that uses it, the protocol wasn't standing on its own in general.
More importantly: RSS hasn't gone anywhere. 100% of my podcasts are discovered via RSS or Atom updates. It's entirely possible that RSS was just a bad fit for aggregating updates to pages people read (in fact, I'd argue that this very federated-protocol architecture we're on right now, Mastodon, represents a better model for being kept up-to-date on news).
@mark @jwz I will stop responding to your posts until you actually go read _in detail_ the two articles of mine I've linked above, since this has all been addressed there and you've obviously either not read them with enough core or are just sealioning, and in either case you're not worth responding to.
@oblomov @jwz Fair enough. I skimmed them but will be unlikely to make time to read them in depth because none of what was said in the skim hadn't been said elsewhere in the conversational zeitgeist I've seen online so far on the topic. The situation seems thoroughly camped into, broadly speaking, "Google cannot be trusted therefore this is bad" and "This is a technical decision that will have nearly no bearing on end-users."
Credit where it's due: as a work of art, xslt.rip summarizes the two camps extremely well.
I wish you well in your endeavor.
Pxl Phile
Geoff Coffey@jwz Ok but no joke XSLT was excellent and the lack of anything similar for JSON transformation is a genuine loss I lament regularly.
whut
Eric Vitiello@jwz I may be in the minority but I really liked XSLT. My whole website was at one point a stack of XML with XSLT transforming it into HTML and SVG