kenferry
7 hours ago
Seems rather absolutist. XSLT was an idea that sounded good, but in practice was quite awkward (like many xml technologies) and never got off the ground. Do we really need to hang every failed experiment around browser vendors' necks forever? I would prefer they work on things people care about.
From one of the issue trackers:
"While it's important to not break existing web content, it's also important to prevent security vulnerabilities. XSLT has been in maintenance mode in browsers and has been an ongoing source of security issues."
gucci-on-fleek
4 hours ago
> and never got off the ground […] failed experiment
I wouldn't quite call it it a failed experiment; I've personally used it in a couple of my websites [0] and I've had pretty good experiences with it.
> it's also important to prevent security vulnerabilities
The security concerns seem disingenuous to me, since sandboxing libxslt has already been implemented and would immediately solve any security concerns [1].
> Seems rather absolutist.
I agree. As far as I can tell, this is just some developers at Google making a poor technical decision, and not some greater conspiracy against the open web.
pmarreck
6 hours ago
> and never got off the ground
LOL, what?? I used to work in shops, circa early 2000's, where 100% of the report-generation was driven by XSLT. I'm pretty sure it had massive corporate penetration at some point, especially when riding along with Microsoft's pervasive-at-the-time support of the standard. And I'm sure it's still got decent penetration out there.
xp84
6 hours ago
> had
> massive corporate penetration
By this standard, every desktop should still ship with a copy of Internet Explorer 6. Most of what made it "special" compared to say, the contemporary Firefox 2.0, was its huge pile of special sauce used only in corporate settings. That stuff had massive corporate penetration as well, but we moved on because ActiveX in the browser wasn't worth the security cost of keeping it around.
If there are important legacy things sitting around corporate environments that literally require XSLT to function, they've had over a year of warning in which to sort it out -- port it to something else, or, pick some alternative browser, pin its version, and set it up with a proxy that can only access your weird XSLT sites. They'll be improving their own security posture with that move, as well!
Random corporations' failure to plan doesn't constitute a need for the rest of the world to continue to maintain obsolete technologies for free.
randallsquared
4 hours ago
> By this standard, every desktop should still ship with a copy of Internet Explorer 6
But the original statement being objected to was "never got off the ground", and while you can say many things about IE6, that isn't one.
cowlevel
6 hours ago
You can install an XSLT processor plugin in a corporate setting. This is about the public web.
IMO the main use of client-side XSLT was making people say "what the-?" when they viewed source, because they'd get an XML document full of your entirely custom tags, not the output of the XSLT processor. Which is pretty cool in itself but not worth the attack surface.
Telemakhos
4 hours ago
You're ignoring the actual use case: people would view the XML with XSLT in browser and see a web page in a format that they could read and appreciate, and computers could read the XML ignoring the XSLT and get a dataset that they could manipulate for further purposes.
Consider an API that returns not JSON but XML: a human viewing that data in a web browser would see a web page depicting the data, while a script fetching that data would get the underlying data as an intelligible and manipulable structure for further operations. The example usually given was a CD tracklist: a human would get a readable list, while a script would get data about titles, artists, etc, and could file that in a music library or perform other operations on it. I worked with TEI: a human could read a book encoded as TEI and transformed by XSLT into a web page that reproduced the text of the book, but a CMS collecting texts into a corpus could pull bibliographic data from the XML and index the TEI file among others into a library. The main idea was that underlying data should be separated from its presentation, so that XML files would function as data models for different consumers, while XSLT transformed that data for human consumers, and automated consumers would operate on the underlying model. If you remember the late 90s and early 00s, separating data from presentation of data was a major goal, and XSLT did that.
cowlevel
3 hours ago
Yeah but you can also implement that by appending .json to the path to get JSON, like in the old reddit API
eichin
4 hours ago
Heh, flashbacks to Adero - a y2k-ish startup to do "the Akamai thing" but with XSLT running on our edge nodes, so you could have sophisticated personalization while the upstream site had hugely cacheable snippets. (One of our reference examples was a sports news site where you specified your interests and got a custom "newspaper" - assembled in our edge servers, not your browser.)
(I suspect if you had a catalog of "ways your startup can choose badly" for that era, we hit a lot of them. My top 3 were "attempt to do server balancing with a day's worth of latency data, using a perl script that took more than 24 hours to run and sometimes failed entirely", "Having a 20 person IT department to manage an outlook server for a 100 person company", and "Offering a senior engineer a VP position with firing authority to fix the outlook problem" :-)
ergonaught
6 hours ago
We used XSLT for literally every UI, for generating C++ for certain types of classes, and for generating SQL for very large reporting systems, etc. It was used in damned near everything.
Bummer, I guess.
genxy
an hour ago
I am sure someone is working on a polyfill using wasm. This won't unbreak the rest of the web, but it will still allow for a clean separation of concerns.
I know "chrome is their browser" but Google has no business unilaterally decided what the fucking web runs now. They are just a big fucking adriddled bully.
xp84
6 hours ago
Did any of that stuff happen in the browser, though?
I never learned the first thing about it, other than its name, so I'll admit ignorance.
ergonaught
an hour ago
For the UI, yes. It gave us (and our customers) a great deal of flexibility.
I can only assume we would go in a different direction, today, even if XSLT weren't "dying", but it really did fit our use case really well.
kenferry
6 hours ago
In a browser? I mean, maybe so in which case, interesting. I agree it had and has more use outside the browser.
jauntywundrkind
6 hours ago
I saw it get used a lot.
The "we tried, it failed" story would be a lot more interesting in its bland boring shitty conservative dismissal rejection if the browsers had ever tried to support it. XSLT shipped 1.0 in 1999 and the browsers afaik never once ever did any further work, never bothered on the 2.0 (2007, incredibly better), 3.0 (2017), or new 4.0 (upcoming). Devs had to deal with the pretty jank early version, which changed a lot for 2.0! Massively! For massive betterment.
It's so so cheap and easy to discard and downput. I recommend to those desiring the path of the engineer the builder to be more sensitive. To tune in to what is good, what aspects did work. Look for value. The people in this world need those instincts, to look and assess and collect. The story of why things maybe don't work is the contrapositive failure, the same post hoc ergo propter hoc, but for the failure case. It's wrong, or at least, it usually misses the realer stories. It's a bad analysis filter.
This refusal to ever see the maybe, better, possibly rejects your ability to see and tune for more. Progress on, stop rejecting. Get good. Find good. Look for the good. Bring out the good. Or if not, consider the perhaps. If nothing else, more neutrally: let not you tie your wagon every time to the current of what is! (Another world is possible.)
kenferry
5 hours ago
Ok, well, in good humor I will engage with the ideas of xslt in the browser now.
I see the appeal of being declarative about transforming your data like this, but I don’t think it works out. Simple cases are ok, but then either (1) when things get more demanding your users hit a wall and have to rewrite in some other environment (2) you have to add a lot of complexity and typical programming language flow control constructs, which are an awkward fit, or maybe (3) you provide some kind of "unsafe" trap door to a more traditional environment. XSLT mostly went with 2, and the result is that you get a programming language that is very un-ergonomic for anything other than simplest cases. Maybe I'm overly sensitive to this because there are non-xml, non-xslt cases where I have committed to paths like this and have spent more brainpower than the problems merited on trying to do it "right", where right was kind of arbitrary. It can be an addictive brainteaser!
Second, there's just not much reason for it to be in the browser. XML served on a site is very likely to be view on the data, not the native form of the data on the backend. It's much more straightforward to have whatever transformations you need to do start from the native form of the data than to stack the transformations over xml. And if XSLT is what's convenient? Great! Do it on the back end. In 1999 that didn't seem like such an easy decision.
cxr
4 hours ago
> there's just not much reason for it to be in the browser
Aside from the fact that it's a widely implemented, mature standard and the reason given in the article which happens to be one of the most important things in world of browsers ("Don't break the Web"), sure, there's no reason.
ProAm
5 hours ago
> Do we really need to hang every failed experiment around browser vendors' necks forever?
<blink> has entered the chat </blink>