121–130 of 352 posts
Earlier quoted context omitted.
The issue in question is just one of the several long-unfixed vulnerabilities we know about, from a library that doesn't have that many hands or eyes on it to begin with.
And why doesn’t Google contribute to fixing and maintaining code they use?
they went from a clean scheme based standard to a human-unreadable "use a GUI tool" syntax.
st text serna was a wysiwyg XML FO rendering editor: throw in call stylesheets and some input XML, wysiwyg edit away
but xslt didn't take off nor did derived products.
I think that's sad. XSLT is in my point a view a very misunderstood technology. It gets hated on a lot. I wonder if this hate is by people who actually used and understood it, though. In any case, more often than not this is by people who in the same sentence endorse JavaScript (which, by any objective way of measuring is just a language far more poorly designed).
XSLT is like programming with both hands tied behind your back, or pedaling a bicycle with only one leg. For any non-trivial task, you quickly hit a wall of complexity or impossibility, then the only way XSLT is useful is if you use Microsoft's non-standard XSLT extensions that let you call out to JavaScript, then you realize it's so easy and more powerful to simply do what you want directly in JavaScript there's absolutely no need for XSLT.
I understand XSLT just fine, but it is not the only templating language I understand, so I have something to compare it with. I hate XSLT and vastly prefer JavaScript because I've known and used both of them and other worse and better alternatives (like Zope Page Templates / TAL / METAL / TALES, TurboGears Kid and Genshi, OpenLaszlo, etc).
https://news.ycombinator.com/item?id=44396067
https://news.ycombinator.com/item?id=22264623
https://news.ycombinator.com/item?id=28878913
https://news.ycombinator.com/item?id=16227249
>My (completely imaginary) impression of the XSLT committee is that there must have been representatives of several different programming languages (Lisp, Prolog, C++, RPG, Brainfuck, etc) sitting around the conference table facing off with each other, and each managed to get a caricature of their language's cliche cool programming technique hammered into XSLT, but without the other context and support it needed to actually be useful. So nobody was happy!
>Then Microsoft came out with MSXML, with an XSL processor that let you include tags in your XSLT documents to do all kinds of magic stuff by dynamically accessing the DOM and performing arbitrary computation (in VBScript, JavaScript, C#, or any IScriptingEngine compatible language). Once you hit a wall with XSLT you could drop down to JavaScript and actually get some work done. But after you got used to manipulating the DOM in JavaScript with XPath, you being to wonder what you ever needed XSLT for in the first place, and why you don't just write a nice flexible XML transformation library in JavaScript, and forget about XSLT.
One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone w…
I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one. "XSLT is currently the only way to make feeds into something that can still be viewed." You could use content negotiation just fine. I just hit my personal rss.xml file, and the browser sent this as the Accept header: text/html,application/xhtml+xml,applica…
One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone w…
FWIW the original post explicitly mentioned this use case and offered two ways to workaround.
For RSS/Atom feeds presented as links in a site (for convenience to users), developers can always offer a simple preview for the feed output using: https://feedreader.xyz/
Just URL-encode the feed like so: https://feedreader.xyz/?url=https%3A%2F%2Fwww.theverge.com%2...
...and you get a nice preview that's human readable.
One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone w…
I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one. "XSLT is currently the only way to make feeds into something that can still be viewed." You could use content negotiation just fine. I just hit my personal rss.xml file, and the browser sent this as the Accept header: text/html,application/xhtml+xml,applica…
Once upon a time, nice in-browser rendering of RSS/Atom feeds complete with search and sorting was a headliner feature of Safari.
https://www.askdavetaylor.com/how_do_i_subscribe_to_rss_feed...
Earlier quoted context omitted.
> And so does about 1-2% of all Web users. To put that in context, about 6 percent of US homes have no internet access at all. The “I turn off JS” crowd is at least 3x smaller than the crowd with no access at all. The JS ship sailed years ago. You can turn it off but a bunch of things simply will not work and no amount of insisting that it would not be required will change that.
I'm hearing you say, "don't waste your breath because change is not possible." And there you have your self-fulfilling prophecy. To quote someone who lived before me: don't accept the things you cannot change. Change the things you cannot accept. And the no-JS ship has not sailed. Government websites require accessibility, and at least in the UK, do not rely on JS.
I’m not saying change is not possible. I’m saying the change you propose is misguided. I do not believe the entire world should abandon JS to accommodate your unusual preferences nor should everyone be obliged to build two versions of their site, one for the masses and one for those with JS turned off.
Yes, JS is overused. But JS also brings significant real value to the web. JS is what has allowed websites to replace desktop apps in many cases.
Earlier quoted context omitted.
I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty. Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!
It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams... I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every pop…
Earlier quoted context omitted.
Blame Apple and Mozilla, too, then. They all agreed to remove it. They all agreed because XSLT is extremely unpopular and worse than JS in every way. Performance/bloat? Worse. Security? MUCH worse. Language design? Unimaginably worse. EDIT: I wrote thousands of lines of XSLT circa 2005. I'm grateful that I'll never do that again.
> Security? MUCH worse. Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense. Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)
https://www.offensivecon.org/speakers/2025/ivan-fratric.html
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
https://nvd.nist.gov/vuln/detail/CVE-2025-7425
https://nvd.nist.gov/vuln/detail/CVE-2022-22834
(And, for the record, XSL is Turing-complete. It has xsl:variable, xsl:if, xsl:for-each, and xsl:apply-template function calls.)
Earlier quoted context omitted.
I'm hearing you say, "don't waste your breath because change is not possible." And there you have your self-fulfilling prophecy. To quote someone who lived before me: don't accept the things you cannot change. Change the things you cannot accept. And the no-JS ship has not sailed. Government websites require accessibility, and at least in the UK, do not rely on JS.
Then you misheard me. I’m not saying change is not possible. I’m saying the change you propose is misguided. I do not believe the entire world should abandon JS to accommodate your unusual preferences nor should everyone be obliged to build two versions of their site, one for the masses and one for those with JS turned off. Yes, JS is overused. But JS also brings significant real value to the web. JS is what has allo…
> JS is what has allowed websites to replace desktop apps in many cases.
Horribly at that, with poorer accessibility features, worse latency, abused visual style that doesn't match the host operating system, unusable during times of net outages, etc, etc.