> its not clear why, say, Chrome or Firefox wouldn't want to take over XSLT/libxml2 development

Very few people actually like XSLT, presumably including the Chrome and Firefox devs. I know XSLT has its share of supporters and that's fine. I'm not here to argue to merits of XSLT – or lack thereof – but we need to be honest about this. They are the proverbial Black Metal fans; everyone else just thinks it's bloody noise.

In addition, many people have grown towards the idea that importing these large C libraries for little used features is just not a good idea in the first place. And that makes libxml and libxslt a dead end. The entire business with XSLT was kicked off by a bunch of security bugs.

Finally, I think a decent case can be made to slim down the "web platform" a bit. If you want XSLT you can still "bring it yourself", but does every browser need to implement it to be "standards compliant"? Seems like a bad trade-off to me. It's a win for newer browsers like Servo or Ladybird if they don't need to worry about XSLT.

So in short, it's not just a problem of "adding some more people to libxml", although obviously that is a problem.

Just for the sake of example I'm one of the people who would be a candidate to take over development, but same as anyone else I have little desire to be stuck maintaining unnecessarily complex functionality. Instead I've chosen to work on reimplementing XML and its utilities from the ground up without making the same errors that made XML so miserable to users and implementers both...

> a decent case can be made to slim down the "web platform" a bit. If you want XSLT you can still "bring it yourself"

Completely agree, but there remains the massive unsolved issue of templating in HTML (at the moment XSLT is the only way to run a templated HTML website on s3 without a massive pile of javascript).