"Remove mentions of XSLT from the html spec" • Hacker News Board

Re: "Remove mentions of XSLT from the html spec"

#321

Post by ArchOversight » Tue, Aug 19, 2025, 6:52 PM UTC

zetafunction wrote: post #281

mananaysiempre wrote: post #251

Earlier quoted context omitted.

> [T]he maintainer of libxslt has stepped down: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 ... Largely because of lack of help from major users such as browsers.

Disclaimer: I work on Chrome and I have contributed a (very) small number of fixes to libxml2/libxslt for some of the recent security bugs. Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance: - libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constra…

Sounds like libxslt needs more than just a small number of fixes, and it sounds like Google could be paying someone, like you, to help provide the necessary guidance and feedback to increase the usability and capabilities of the library and evolve it for the better.

Instead Google and others just use it, and expect that any issues that come up to be immediately fixed by the one or two open source maintainers that happen to work on it in their spare time. The power imbalance must not be lost on you here...

If you wanted to dive into what [3] does, you could do so, you could then document it, or refactor it so that it is more obvious, or remove the compile time flag entirely. There is institutional knowledge everywhere...

Re: "Remove mentions of XSLT from the html spec"

#322

Post by goku12 » Tue, Aug 19, 2025, 6:53 PM UTC

maratc wrote: post #77

nicce wrote: post #50

Earlier quoted context omitted.

Why flagged? The post was reasonable.

Probably labeling a removal of a format (which is somewhat niche anyway) as "killing the open web" was a bit hyperbolic and not entirely warranted in this case. Imagine that tomorrow, Google announces plans to stop supporting HTML and move everyone to its own version of "CompuServe", delivered only via Google Fiber and accessible only with Google Chrome. What headline would you suggest for that occasion? " Google is…

> Probably labeling a removal of a format (which is somewhat niche anyway) as "killing the open web" was a bit hyperbolic and not entirely warranted in this case.

Incorrect on three counts. That article lists a bunch of useful technologies that were rejected at WHATWG with unconvincing reasons against massive public protests. It wasn't just labeling the removal of a format - that's a misrepresentation. The second is your characterization of calling XSLT niche. The article makes a case for why it is like that why it shouldn't be so. It's niche because it is neglected by the browser devs themselves. It hasn't been updated to the latest standard in a long time and it isn't maintained well enough to avoid serious bugs. And finally the third - "killing the open web" being a hyperbole. I don't even know where to start. There was a joke that web standards are proposed by someone from Google, reviewed and cleared from someone else from Google and finally approved by someone from Google. We saw this in action with WEI (The only reason for its partial rollback being the unusual attention and the massive backlash they faced from the wider tech community and mainstream media - including ours). At this point the public discussion there is just a farce. I don't know how many times this keeps repeating. That article shows many examples of this. Let me add my own recollections of the mockery to the mix - inclusion of EME and the rejection of JPEG-XL (technically not a part of the standard, but it is in a manner of speaking). It doesn't even resemble anything open.

I will be surprised if this comment doesn't receive a ton of negative votes. But there is no point in being a professional and in being here, if I'm unwilling to oppose this in public interest. The general conduct of WHATWG antithetical to public interest and are meant to escape the attention of the non-tech public. And even the voice of the savvy public is ignored repeatedly and contemptuously. It's not difficult to identify the corruptive influences of private commercial interests on these standards - EME and WEI being the tip of the iceberg. And let's not ignore the elephant in the room. It getting harder by the day to use a browser (web engine to be more precise) of your choice. In this context, the removal of XSLT isn't just a unilateral decision (please don't quote Firefox, Safari or Edge. Their interdependence is nothing short of a cabal at this point), its justification is based on problems that they themselves created.

Again expecting to be downvoted, it's hard to miss the patterns - arguments against XSLT that ignore the neglect that lead to it, and the dismissal of public comments (then why discuss it where anyone can read and post? why bill it as open?). The same happened with SMIL, JPEG XL,... It's tense to suggest attempts to drown out the opposition (I know it has a name. But that's enough trigger some), even if there are sufficient reasons to suspect it. But the flagging of that other article is a blatant indicator of that. Nothing in that article is factually false or remotely hyperbolic. Many of us are first hand witnesses of the damages and concerns it raises. The article is a good quality aggregation of the relevant history. Who is so inconvenienced by that? The only reason I can think of is the zeal to censor public interest opinions. Is the hubris in the group issue tracker spreading to public tech fora now? Conduct like this makes me lose hope that the web platform will ever be the harbinger of humanity's progress that it once promised to be. Instead it's turning out to be another slow motion casualty of unbridled greed.

PS: The flag has been cleared by the admins. But their (!admin) intent is unmistakable.

Re: "Remove mentions of XSLT from the html spec"

#323

Post by mr_toad » Tue, Aug 19, 2025, 6:54 PM UTC

sedatk wrote: post #308

I love XSLT. I released a client-side XSLT-based PWA last year ( https://github.com/ssg/eksi-yedek - in Turkish). The reason I had picked XSLT was that the input was in XML, and browser-based XSLT was the most suitable candidate for a PWA. Two years ago, I created a book in memory of a late friend to create a compilation of her posts on social media. Again, thanks to XSLT, it was a breeze. XSLT has been orphaned on t…

I’d just use the browsers XML parser and javascript for the transformation. Which is what I assume a putative XSLT javascript library would do.

And if you’re leaning towards a declarative framework, use React.

Re: "Remove mentions of XSLT from the html spec"

#324

Post by ArchOversight » Tue, Aug 19, 2025, 6:55 PM UTC

spankalee wrote: post #171

kg wrote: post #133

Earlier quoted context omitted.

Former Mozilla and Google (Chrome team specifically) dev here. The way I see what you're saying is: Representatives from Chrome/Blink, Safari/Webkit, and Firefox/Gecko are all supportive of removing XSLT from the web platform, regardless of whether it's still being used. It's okay because someone from Mozilla brought it up. Out of those three projects, two are notoriously under-resourced, and one is notorious for con…

Another way to look at this is: Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?

If this is the reason to remove and or not add something to the web, then we should take a good hard look at things like WebSerial/WebBluetooth/WebGPU/Canvas/WebMIDI and other stuff that has been added that is used by a very small percentage of people yet all could contain various security bugs...

If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are trying to have the browser replace the whole OS.

Re: "Remove mentions of XSLT from the html spec"

#325

Post by masfuerte » Tue, Aug 19, 2025, 6:56 PM UTC

MrJohz wrote: post #283

LegionMammal978 wrote: post #259

Earlier quoted context omitted.

> It is a balance (compatibility vs attach surfaces). What I'm trying to say is that it's a false dichotomy in most cases: implementations could almost eliminate the attack surface while maintaining the same functionality, and without devoting any more ongoing effort. Such as, for instance, JS polyfills, or WASM blobs, which could be subjected to the usual security boundaries no matter how bug-ridden and ill-maintain…

Sure, but this requires someone sitting down and writing the JS polyfill, and then maintaining it indefinitely. And for something as complicated as XSLT, that will surely be indefinite maintenance, because complicated specs beget complicated implementations. In the absence of anyone raring to do that, removal seems the more sensible option.

The vendor discussion on removing XSLT is predicated on someone creating a polyfill for users to move to. It is not an unreasonable assumption because a polyfill can be created fairly trivially by compiling the existing XSLT processor to WASM.

And it is also fairly trivial to put that polyfill into the browsers.

The Chrome team has been moaning about XSLT for a decade. If security was really their concern they could have replaced the implementation with asm.js a decade ago, just as they did for pdfs.

Re: "Remove mentions of XSLT from the html spec"

#326

Post by AlienRobot » Tue, Aug 19, 2025, 6:57 PM UTC

chrismorgan wrote: post #266

solardev wrote: post #208

Earlier quoted context omitted.

Bring back VRML! Seriously though, if I were forced to maintain every tiny legacy feature in a 20 year old app... I'd also become a "former" dev :) Even in its heyday, XSLT seemed like an afterthought. Probably there are a handful of legacy corporate users hanging on to it for dear life. But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XS…

> But if infinitely more popular techs (like Flash or FTP or non HTTPS sites) can be deprecated without much fuss... I don't think XSLT has much of a leg to stand on... Flash was not part of the web platform. It was a plugin, a plugin that was, over time, abandoned by its maker. FTP was not part of the web platform. It was a separate protocol that some browsers just happened to include a handler for. If you have an F…

Flash was the best part of the web, though.

Re: "Remove mentions of XSLT from the html spec"

#327

Post by mananaysiempre » Tue, Aug 19, 2025, 6:57 PM UTC

zetafunction wrote: post #281

mananaysiempre wrote: post #251

Earlier quoted context omitted.

> [T]he maintainer of libxslt has stepped down: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913 ... Largely because of lack of help from major users such as browsers.

Disclaimer: I work on Chrome and I have contributed a (very) small number of fixes to libxml2/libxslt for some of the recent security bugs. Speaking from personal experience, working on libxslt... not easy for many reasons beyond the complexity of XSLT itself. For instance: - libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constra…

> libxslt is linked against by all sorts of random apps and changes to libxslt (and libxml2) must not break ABI compatibility. This often constrains the shape of possible patches, and makes it that much harder to write systemic fixes.

I’m having trouble expressing this in a way that won’t likely sound harsher than I really want, but, uh, yes? That’s the fundamental difference between maintaining a part of the commons that anybody can benefit from and a subdirectory in a monorepo. The bazaar incurs coordination costs, and not being able to go and fix all the callers is one of them.

(As best as I can see, Chrome’s approach is largely to make everything a part of the monorepo, so maintaining a part of the commons may not be high on the list of priorities.)

This not to defend any particular ABI choice. Too often ABI is left to luck and essentially just happens instead of being deliberately designed, and too often in those cases we get unlucky. (I’m tempted to recite an old quote[1] about file formats, which are only a bit more sticky than public ABI, because of how well it communicates the amount of seriousness the subject ought to evoke: “Do you, Programmer, take this Object to be part of the persistent state of your application, to have and to hold, through maintenance and iterations, for past and future versions, as long as the application shall live?”)

I’m not even deliberately singling out what seems to me like the weakest of the examples in your list. It’s just that ABI, to me, is such a fundamental part of lib-anything that raising it as an objection against fixing libxslt or libxml2 specifically feels utterly bizarre.

[1] http://erights.org/data/serial/jhu-paper/upgrade.html

Re: "Remove mentions of XSLT from the html spec"

#328

Post by o11c » Tue, Aug 19, 2025, 7:01 PM UTC

jerf wrote: post #303

xg15 wrote: post #185

Earlier quoted context omitted.

I think this discussion is quite reasonable, but it also highlights the power imbalance: If this stuff is decided in closed meetings and the bug trackers are not supposed to be places for community feedback, where can the community influence such decisions?

Honestly, your chance to impact this decision was when you decided what technologies to use on your website, and then statistically speaking [1], chose not to use XSLT in the browser. If the web used it like crazy we would not be having this conversation. Your other opportunity is to put together a credible plan to resource the XSLT implementations in the various browsers. I underline, highlight, bold, and italicize…

Counterpoint: most websites are not useful. If we only count useful websites a much higher percentage of them are using XSLT.

But useful websites are much less likely to be infested by the all consuming Goo admalware.

Re: "Remove mentions of XSLT from the html spec"

#329

Post by pjmlp » Tue, Aug 19, 2025, 7:01 PM UTC

danans wrote: post #287

pjmlp wrote: post #249

Earlier quoted context omitted.

That is a VM, and actually maybe eventually it will be on top of Webassembly, how things are going.

> That is a VM... So is WSL on Windows. I wouldn't call Windows "just the web". There's also nothing stopping me from building and running local desktop GUI software on the VM. In fact, a VM is better in that I can back up and restore the image easily.

WSL and other VMs are the Year of Desktop Linux finally coming true, nothing to do with Web.

Re: "Remove mentions of XSLT from the html spec"

#330

Post by ArchOversight » Tue, Aug 19, 2025, 7:04 PM UTC

codedokode wrote: post #194

geocar wrote: post #175

Earlier quoted context omitted.

> This is actually not a bad idea. Why should the browser contain a specific template engine, like XSLT XSLT is a specification for a "template engine" and not a specific engine. There are dozens of XSLT implementations. Mozilla notably doesn't use libxslt but transformiix: https://web.mit.edu/ghudson/dev/nokrb/third/firefox/extensio... > and not Jinja for example? Jinja operates on text, so it's basically document.w…

> I've been looking at it as a secret weapon: I've been using it for the last twenty years because it's faster than everything else. Serving a server-generated HTML page could be even faster.

That assumes the server has a lot of additional CPU power to serve the content as HTML (and thus do the templating server side), whereas with XSLT I can serve XML and the XSLT and the client side can render the page according to the XSLT.

The XSLT can also be served once, and then cached for a very long time period, and the XML can be very small.