No, Google Did Not Unilaterally Decide to Kill XSLT
56 points by simonw
56 points by simonw
This whole thing has very poor optics and it’s mostly Google’s fault.
Google has a tight grip on Chrome. It pushed a lot of questionable features (WebUSB?). Chrome also historically gamed the process: they implemented features on thin specs and then fast-tracked them into standards based on “existing implementations”.
Cited security issues are also Google’s doing. I don’t meant that Google put them into libxslt. But Google had resources for Project Zero to uncover them and dump a whole lot of them on the maintainer.
Now Google employee comes with a proposal to remove XSLT from the spec.
There was no proposal to fix libXSLT, or to replace it with something more secure. There was no proposal to upgrade XSLT to 3.0/3.1 in the spec. Was there an internal pitch from Chrome team to Google for more resources to do any of these? We don’t know. There was some time between the issue rased on the meetings (as far as I can tell it was discussed on calls in March) and the Issue on the repo. Given the massive dominance of Chrome, amount of money Google has, and the fact that Chrome is absolutely totally without doubt under Google’s control it’s only natural people want to see those money do something good. Google can not have it both ways: absolute control and “no money” shield.
Now, let’s take at the face value claims of following the process. The discussion was shut down. There’s obviously a passionate user base. The technology is used: there’s a lot examples out there. The numbers provided are above Chrome’s own support thresholds, and at the same time many expressed doubts about their accuracy (leaning towards the numbers being lower than the actual use).
Chrome team now claims that PRs don’t mean anything. It’s just to illustrate what the proposal entails. It’s actually a part of the process. And I would agree that a PR to spec is a useful illustration. But a PR to Chrome itself? I’m not convinced. I’m willing to bed a full $1 to a charity that the Chrome PR is gonna land anyway. Maybe not this month but likely by the New Year. The spec might not change. After all It’s not illegal to not support the spec in full.
Cited security issues are also Google’s doing. I don’t meant that Google put them into libxslt. But Google had resources for Project Zero to uncover them and dump a whole lot of them on the maintainer.
To add to that, the libxml2/libxslt maintainer finds this kind of work pretty boring and unrewarding, and finds it pretty annoying that Google Project Zero is incredibly well resourced but won’t spend even a dime to actually help fix the issues they report, only pressure unpaid volunteer OSS maintainers about disclosure embargoes and deadlines.
Even more galling is the fact that they’re not lifting a finger to help with fixes despite shipping the libraries as a critical part of their flagship user-facing software.
There was a HN comment that I read yesterday I believe from a Chrome maintainer that suggested they had helped fix various parts of libxslt over the years, but that it was a very difficult process because the library is very complex and does a lot of weird stuff like repurposing fields from libxml for different things and other weird behaviours.
So to a certain extent they’re caught between a rock and a hard place: there’s only so much they can spend on supporting a codebase that is so difficult to maintain, so either they replace it with their own implementation (also by no means an easy task) or rip it out entirely (which produces the outcry we’re seeing now).
This feels like one of those issues where commons ownership breaks down. In a business context, you’d be able to put a price on supporting XSLT for those clients that need it, vs the price of migrating them off it, and you could figure out (roughly) which decision makes the most sense. But because the web specs are essentially commons resources, and because ~nobody pays to use a browser, it’s very difficult to cut support for something that even a handful of people use, right now, for free.
I think there’s a danger of projects like this becoming a kind of vetocracy, where every stakeholder ends up with the right to veto changes that affect them, causing bloat and complexity even where it would be less work overall for the people affected to find a different solution and for the complexity to be removed from the project. I don’t know if this is one of those cases, and I agree that it’s not ideal for, say, the Chrome team alone to decide what’s worth implementing and what isn’t. But in this case, it looks like there’s a lot of consensus that supporting this feature just isn’t worth it from the other two browsers.
~nobody pays to use a browser
That’s because we’re the products. Our eyeballs and clicks are being packaged up and sold by Google to the highest bidder, quite literally.
every stakeholder ends up with the right to veto changes that affect them, causing bloat and complexity
That’s not what causes bloat and complexity. It’s big browser vendors pushing complex features that turn browsers into operating systems that causes bloat. XML and XSLT are a legacy feature from the very days of the birth of the web itself. Gutting them instead of handing the libxml2 maintainer (who is a contractor!) a contract is kinda the perfect analogy of what corporations do with the commons, built by others, that they inherited.
it looks like there’s a lot of consensus that supporting this feature just isn’t worth it from the other two browsers.
It looks like there’s a lot of consensus from users that this feature is very important for the web. Nobody is forcing the browser vendors to be in this business. If they can’t or won’t support users, maybe they shouldn’t be.
It looks like there’s a lot of consensus from users that this feature is very important for the web.
Where are you getting this? It sounds to me like there are a handful of people who use it, no major sites use it, and the overwhelming majority of all sites do not use it.
How many users are you saying should be required to support a few in perpetuity? Should we also bring back JSS and E4X? After all, they had users. Hell popups had users - many more in fact than XSLT or XPATH ever did - as did third party cookies, flash, applets, ActiveX, …
I am sick of people saying a bunch of people brigading a bug report is somehow representative of “the users”.
Gutting them instead of handing the libxml2 maintainer (who is a contractor!) a contract is kinda the perfect analogy of what corporations do with the commons, built by others, that they inherited.
I know plenty of engineers from many companies who put work into trying to resolve security issues in libxml and libxslt, the problem is that they are extremely complex specifications, and it’s hard enough to ensure that the rest of the browser engine is secure. My like image decoding, the security fix would be to offload xml and/or xslt into a separate process, which means coming up with a way to safely pass the xml document back and forth between said processes. I guess in principle you could say “these APIs are only available in workers and allow workers to construct XML nodes, and then require the users to serialize them to pass them back to the host” - obviously this would be expensive - JS workers normally run in process and this would necessarily require moving these specific ones out of process, which would mean being able to know ahead of time what the usage would be.
Anyway, it remains amazing and absurd that people continue to believe that you can just throw more engineers at a project and magically make everything better, which is what people like you are demanding.
no major sites use it,
Bullshit. Some of the biggest websites on the Internet use it. By Google’s own figures there are at least hundreds of millions of pages using it. Get out a calculator and check for yourself.
One of the most important websites that use it is the US government which is required by law to publish bills and laws in XML so that we can mechanically digest them. For example:
https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml
I know plenty of engineers from many companies who put work into trying to resolve security issues in libxml and libxslt,
I doubt that, but so what? Mozilla doesn’t use libxslt so I don’t think it can’t have anything to do with this.
and it’s hard enough to ensure that the rest of the browser engine is secure.
Then what the fuck is the point of all that sandboxing Google does if it doesn’t work?
I suppose it is possible Google is just really bad at programming, and isn’t trying to deliberately confuse people, but then I wonder why anyone would listen to Google.
Where are you getting this?
In the new issue: https://github.com/whatwg/html/issues/11578
which is what people like you are demanding.
It’s not what I’m ‘demanding’…it’s literally what the libxml2/libxslt maintainer is recommending, that he would be incentivized to more quickly triage, embargo, and fix vulns if he was, well, incentivized to do it. I don’t know much about the details of these libraries and how complex they are, but given that he is the maintainer, I am inclined to believe him about the situation more than I am random people on Lobsters.
Where are you getting this? In the new issue: https://github.com/whatwg/html/issues/11578
I literally stated in my comment that this is a tiny group of people brigading a thread. You did not point to the copious and endless real world content, or real world users depending on this feature. You pointed to a thread that was being brigaded by people who do not represent users, do not represent any significant number of sites depending on this. If your defense against me pointing out a thread is being swamped by a minority of users is to point to that thread, that is not a strong argument.
I could literally start a proposal that browsers should support Java directly. Would you consider that user consensus? I would bet such a proposal could get a lot of supporters.
Rather than pointing to such minimal content threads, instead point to the wide spread of websites that actually use XSLT. Not a comment thread filled with low cost, and low effort comments spammed from random users, and then presenting that as if that is a “consensus from users”.
In what world is that that claim true? In what world is that claim not absolutely disingenuous?
Seriously: in what world is the number of comments on what is effectively a highly specialized usenet group in any way remotely representative of the opinions of all web developers, let alone users?
Claiming that that is consensus is absolute BS, and if you don’t understand that I don’t know what to say.
which is what people like you are demanding. It’s not what I’m ‘demanding’…it’s literally what the libxml2/libxslt maintainer is recommending,
No, this thread is about removing xslt from general availability as part of the core web available standards. The position of the libxml maintainer’s recent posts are not relevant to some decision that any browser engine developer has wanted for more than a decade - for me personally approaching two decades now.
The libxml maintainer is (rightfully) complaining the they should not be required to take on the burden of supporting downstream browser engines. But that’s an entirely different and unrelated topic - browser engines having been patching, fixing, and defending their use of libxml for more than a decade. The fact that the libxml container has recognized that they cannot manage the influx of reports (likely being targeted because they do not have the resources of browser engines - security bugs in libxml technically impact browsers, but again browsers actively try to mitigate issues in libxml before they hit the library).
The libxml maintainer’s rightful position of not wanting to deal with endless CVEs being filed on the project due to downstream users - this is a very simple thing to consider: if the bug was exploitable in a browser or OS, why would these reporters spam libxml when they could get money through the various platform programs instead? libxml is targeted by these releases because it’s widely used, and so the report is given more press. I would guess, based on my experience, that they’re getting a constant stream of low quality “security bugs”, increasingly absolute BS from “AI”s by the kind of people who brag about vibecoding as if incompetence laundering was a good thing, the majority of which are useless, wrong, or not actually practically relevant. I don’t have to deal with many such bugs, but the amount of time involved is stupid: the people reporting are desperate to have a CVE that they can claim credit for, and will actively fight any argument that their nonsense is accurate.
If I was an unpaid maintainer dealing with that I would absolutely take the approach of the libxml maintainer, but that is absolutely irrelevant to the decision of browser vendors.
You absolutely cannot just brand people trying to engage with the process in the only way they can as “brigading”. You cannot just decide that clearly everyone is being unreasonable just because they’re unhappy and have a whopping… 3 places to actually engage with the change being suggested.
You did not point to the copious and endless real world content, or real world users depending on this feature
You know how to use Google. It is pointless to engage with you because you do not care about actual use cases beyond “but why aren’t all the websites using XSLT? It must be garbage”
You too can use Google. It would help your case more if you can find concrete examples of XSLT use in production other than styling RSS/Atom feeds. So far, that’s the only use case I have heard of for XSLT use in browsers.
Based on this and other submissions, I feel that browsers are fully justified recommending removal of XSLT. People objecting are mostly relying on outrage at Google, not actual use cases.
If you believe I’m wrong, I’m happy to be corrected.
You pointed to a thread that was being brigaded by people who do not represent users,
Please take a look at the GitHub issue. You will easily find the users.
If your defense against me pointing out a thread is being swamped by a minority of users
You didn’t point to any thread (at least in this sub-thread of the conversation). Please take a look at my link. As I said, many have commented there and given use cases. I don’t know what sort of criteria you have for accepting that something is in use, though. The GH issues are presented as the place to discuss these proposals. So if we don’t even care about that, then why have it? And what would actually satisfy you as valid usage? The World XSLT Association should present their membership numbers and browser-based project statistics?
Hell popups had users - many more in fact than XSLT or XPATH ever did - as did third party cookies, flash, applets
Popups still exist, they’ve been limited but e.g. PayPal still uses them.
Flash has a fully functional polyfill.
It’s perfectly okay to replace XSLT with a built-in browser extension that reimplements it in WASM.
Exactly: the position being presented is that people who want XSLT should simply compile libxml, etc to wasm and use that, rather than requiring the browser to support it natively.
That’s not possible if you want to serve XML, though.
If the browser wishes to expose a new mechanism to allow this (e.g., allow specifying service workers in XML to process that XML) that’d be fine.
But there needs to be a way where I can continue serving plain .xml files and have them transformed for display.
Would the approach of using content negotiation headers work for your use case? I.e. serve rendered html (via server-side XSLT) to browsers and other clients requesting html, and serve the raw XML files the rest of the time (or to clients explicitly requesting XML).
I serve XML from 16MHz 8-bit arduinos, which allows the same document to be used by automated tooling or displayed to users using client-side XSLT included from an external server.
I’m not attached to XSLT as a technology, just to the functionality. If I could use <?xsl-stylesheet to point at a JS service worker to transform the XML, that’d be fine too. (It’d even be possible to just write an XSLT polyfill as service worker?)
How is this not a big, complex feature? It’s full of idiosyncratic bugs, it’s caused multiple security issues and, as I said, the implementation is difficult to develop with. I don’t think there’s any way of pretending that XSLT isn’t complex.
So it’s rather a question of: which big, complex feature should browsers be spending their resources on? This, or something like WebUSB? Because that’s the whole issue here is: given a limited number of resources, what should browsers be focusing on?
As I said in the previous comment, the danger is that this decision becomes down to veto rights: as long as there is at least one person using XSLT, then they will always get to veto any changes regarding XSLT. This runs into issues at extreme scales: imagine there truly was only one person using XSLT, and a team working for each browser to support the feature. Would that be proportionate or sensible? Clearly not. At some point, you need to prioritise resources.
I don’t have enough data or experience developing a browser to make a guess at what the correct decision here is, and I can fully believe that ultimately it makes more sense to keep XSLT in browsers. But I don’t get this idea that we should expect browsers to only develop the features we like and prioritise their resources only on what we’re interested in. My needs in a browser are clearly different from yours, but I don’t think it’s helpful playing the entitled user and trying to convince anyone that my needs are more important than yours.
I don’t think the slippery slope of argument of ‘what if it’s just one user with veto power over the whole web platform’ is very helpful. Mainly because it’s just not reality. If you look at the related issue: https://github.com/whatwg/html/issues/11578 …many people have presented their use cases and described how they built their careers using XSLT and the web. Can we just say to them ‘oh you’re not important enough so you don’t get to have a say in the web platform’?
I don’t know what the right balance is either but surely it’s not browser vendors getting away with claiming they don’t have enough resources while at the same time we can see that they are making billions in ad revenues.
Can we just say to them ‘oh you’re not important enough so you don’t get to have a say in the web platform’?
Yes, exactly, that’s the veto right that I’m talking about. The issue tracker does not show a representative sample of users, it shows (naturally) a biased sample of users who would be affected by this issue. The challenge, then, is to figure out how that sample relates to the rest of the users, and what a proportionate solution is. Do the needs of the people in the issue tracker outweigh the additional costs and complexity that XSLT brings? The danger is that one mistakes loudness for necessity. A number of very vocal users may still represent a tiny minority of the total number of users.
That’s why I talked about how a business with paying customers might approach this: if you’ve got a really obscure feature in the codebase that causes a lot of effort, but it’s still used by a handful of customers, how do you make the decision to remove it? At some point, it will be cheaper to help migrate those customers off this feature than to continue supporting them using it. If you take any customer complaint as a sign that you need to keep on supporting a feature, you’ll end up supporting it forever, even if that is more wasteful and less efficient for yourself and all your other customers.
With a commons project like the browser specs, you can’t make a simple financial comparison like that, but that doesn’t mean that there aren’t still costs and benefits, they’re just not written down on a ledger sheet. But because it’s harder to properly estimate those costs and benefits, the power of the veto becomes more significant.
many people have presented their use cases and described how they built their careers using XSLT and the web
Are those careers dependent on XSLT support in browsers?
My intuition is that the vast, vast majority of XSLT usage happens server-side, which is entirely independent of whether web browsers support XSLT or not.
they’re caught between a rock and a hard place: there’s only so much they can spend on supporting a codebase that is so difficult to maintain
That sounds like Google is saying they’re impotent and programming is hard. Why should we listen to them about anything?
it looks like there’s a lot of consensus that supporting this feature just isn’t worth it from the other two browsers
I think you’re mistaken. Apple actually said they’d cautiously consider following other browsers, and Mozilla doesn’t use libxslt so any claims about libxslt being relevant are only relevant to Google – so it seems very plausible to me they only voted with Google because Google pays them.
That’s concerning to me because it means Mozilla’s possibly thrown in the towel and decided they’re not making a web browser anymore, but resigned to manufacture evidence that Google has competition.
Why shouldn’t we listen to them? They’re the people developing Chrome! They’re one of a select group of people who have experienced the challenges of developing a browser, unlike the rest of us in the peanut gallery.
I don’t always agree with the direction the web platform is going, or the decisions they’re making, but I don’t think there’s any reason to suggest that they’re lying here, is there?
I think you’re mistaken. Apple actually said they’d cautiously consider following other browsers, and Mozilla doesn’t use libxslt so any claims about libxslt being relevant are only relevant to Google – so it seems very plausible to me they only voted with Google because Google pays them.
As I understand it, Mozilla proposed the idea at a recent WHATNOT. They do have their own implementation, but the impression I get is that their implementation is also just as buggy and insecure as the Chrome one (or at least: it is buggy and insecure, and enough so that it is a regular source of problems).
I don’t get why you are reaching for a conspiracy here when the significantly simpler answer is that browser developers don’t want to have to maintain code that is causing them problems. If you give me the option, I’ll happily delete all sorts of unnecessary or buggy code from the codebases I have to maintain! You don’t need to line up a secret cabal for me to propose getting rid of cruft!
Why shouldn’t we listen to them? They’re the people developing Chrome!
Nonsense. They’re people who the company pays to not develop Chrome, but to argue on the Internet about breaking Chrome.
They also made this weird claim about %0,001 of page loads affected being a “small number”. That’s billions a year, and that’s nobody’s definition of a “small number”.
They’re one of a select group of people who have experienced the challenges of developing a browser unlike the rest of us in the peanut gallery
They started from KHTML. If that counts, then I’ve developed a web browser too.
Do you wonder why you’re supporting Google in this if you really don’t think you’re smart enough to know better?
I don’t get why you are reaching for a conspiracy here when the significantly simpler answer is that browser developers don’t want to have to maintain code that is causing them problems
Because I don’t share your priors and I disagree with that statement.
It does not make sense to me that spending money on trying to break libxslt and marketing to enlist people like you in support, is somehow cheaper than either bringing it in-house, or adopting a different xslt library, or even writing a new xslt1 implementation. I don’t believe “security issues” makes sense when you have that much sandboxing- because the impact is a crashed tab or potentially a warm CPU- unless it’s the sandboxing itself that’s broken, in which case that should be fixed.
If you give me the option, I’ll happily delete all sorts of unnecessary or buggy code from the codebases I have to maintain!
That’s a big difference between us: I don’t put unnecessary or buggy code in the codebase in the first place, and if I take on someone elses’ code as a dependency, I own all responsibilities that I made a good decision in doing so.
Google will take as much as it can and give as little as it can. This is the natural state of things, even for the company that will do no eviluse any available tactic to maximize value for shareholders and payouts to executives.
But they are not immune to public shaming, and have often grudgingly done things that approach being-the-right-thing when people created enough public visibility of the Google practices.
It’s also high time that people stopped worshiping these companies, as if they were deities. Google is an ok place to work if you get hired by a good team, for as long as that that good manager sticks around. Just like any other company. But the primary upside of the FAANG companies is the pay (if you can find the roles that pay a few mil a year), and outside of that, I’d counsel good engineers to work at a challenging startup instead, 9 times out of 10.
It pushed a lot of questionable features (WebUSB?)
While the idea of WebUSB irks me, the Android Flash Tool is actually a quite nice utility.
And even if chrome wants to drop the dep so bad, they could ship their polyfill hack instead just fine. It’d be slower but whatever. But would they do it?
BTW, there’s a proposal to update XSLT to 3.0 now. Notably, coming from a person unaffiliated with any of the major browsers.
I agree: the fact that it would be slower wouldn’t noticeably matter because it’s hardly ever used.
Mason mentioned that they didn’t have resources to put toward updating their XSLT code, and got widely derided for it. “Google has trillions of dollars!” people hooted. Google has trillions of dollars. The Chrome team very much does not. They probably get, at best, a tiny fraction of one percent of those dollars. Whether Google should give the Chrome team more money is essentially irrelevant, because that’s not in the Chrome team’s control. They have what they have, in terms of head count and time, and have to decide how those entirely finite resources are best spent.
Mason was representing Google in that issue tracker, not just himself. So when he says “we don’t have the resources” then I think a response criticising Google is warranted (of course, not ad-hominems which were also present in that thread). As somebody external to the company, why should I have to worry about what your orgchart and budgets look like? It might explain what’s going on (though it’s already public knowledge that Google is slashing headcount in that team) but it doesn’t invalidate the criticism of Google.
Yep. It’s very valid criticism. And not just against Google, but against the other browser vendors too who’d rather kill XSLT than reach into their trillion dollar pockets.
If browser teams are battling their own bosses and losing, left with no resources to keep open web standards alive, that needs to be “hooted” louder, not dismissed as “essentially irrelevant”.
This can be seen as a vindication of the “web standards are unmanageably complex” crowd. Even companies with trillion dollar pocketbooks are balking at the cost.
Maybe it’s time to slim things down.
Then wouldn’t it be better to redirect funds to existing standards, rather than all the new “standards” Chrome specifically are forcing through?
Of course. However, the incentives at most companies come from shipping features, or at least shifting metrics that can be tied back to revenue, and not towards day to day maintenance,
How many more people should work on chrome? Apparently adding more people will make it better, so how many would you recommend adding? After all that will permit every feature that anyone wants, no matter how few users that is, because as long as you add more people to chrome it will be easily supported, right?
After all the only problem is money, not how many engineers can reasonably work on something at once - everyone knows you can develop more software, faster, and with higher quality if you just get more people.
Obviously it sucks to be a non-rich vendor of course, but most people seem a-ok with a google monopoly on browsers so it doesn’t really matter: people point to their use of “alternative” browsers, that are nothing more the chrome with different ui, as if that’s any different from the “different” browsers in the late 90s early 2000s which were just IE views in a different app window.
But more seriously: XLST is not widely used, it has a massive amount of complexity, and a long track record of security vulnerabilities. You’re saying google needs to maintain it (or things like it) for your specific use case, even though it’s pretty much not used anywhere, so that’s necessarily going to mean something else gets dropped - so what feature should be dropped instead? There are very few web standards that are used less widely than xslt and xpath, and most - if not all - of those are vastly simpler, so it’s presumably going to be a matter of dropping/abandoning something that is more widely used.
how many engineers can reasonably work on something at once
Chrome is not just one thing though, it’s made up of many little pieces all maintained by many people inside and outside Google. Libxml2/libxslt are literally maintained by an unpaid volunteer who got tired of Google Project Zero pressuring him every time them found a vuln. He became very aware that GPZ is incredibly well-funded while Google carefully refrains from even tossing a coin in his direction.
[edit: holy wall of text batman!] [further edit: it looks like there is some degree of RISCV support]
And how does that change this from “adding more engineers will make everything better?”
Also, let’s be honest: if any of the vendors really wanted to put engineering time and support into xslt - a feature that is basically unused - the most effective way to ensure that it was sufficiently secure for the web environment would be to fork it and integrate it directly into the browser engine and replace all of the internal data structures with the more robust mechanisms of the browser itself - this is not a dig at the authors: libxml (and the xslt and xpath processing) was largely written by volunteers at a time when people only just starting to be aware of the threat model browsers needed to assume, and it was largely focused on handling trusted input (the xml and xslts themselves) before it got hammered into the browser engines where none of the input is trusted.
Many years ago I was involved in merging ksvg2 into WebKit, and it took years of work by multiple engineers to stop that from being the overwhelming source of CVEs - the resolution of which was largely replacing all of the internals and implementation. Again, this is not saying it was bad: it obviously allowed webkit to support SVG faster than it would have been able to otherwise, but it was written without the paranoia required when working on a browser - and before people on me, I spent a lot of time working with folk who worked on Qt and similar to bring the implementation to more complete standards conformance, usable perf, etc - also integrating css, etc at the same time. But none of that was usable in ksvg2 because it was all built upon the data structures and engineering design approach of webkit which was by that time drastically different from khtml as well - people don’t recognize how much work was required to get khtml to the point it was a viable engine for normal users, in many respects it was less capable than ladybird today (though ladybird benefits from vastly vastly better specifications than were available at the time).
Now I do agree that it would have been nice to have been able to have khtml able to simply integrate the webkit code, but khtml was built - at its core - on kde and qt data structures that were simply inadequate (performance, memory use, not so much security at the time - very much security now), however the webkit project happily supported numerous different platform integrations even though that frequently caused problems: QtWebkit, the WxWindows API, gtk, etc alongside many architectures (JSC today is able to generate C interpreters, with or within computed goto). Back at the point of the blink fork I recall bragging about all the code they were removing: that code was the abstractions that were needed to support MacOS, Qt, Windows, Wx*, GTK, and of course Chromium itself and the massive amount of effort required to support V8 in addition to JSC (which supported x86, x86_64, PPC, ARM, Thumb(1&2), SH4, MIPS, … in addition to the aforementioned C backend). I personally did a lot of the design and development required to support IM/IMEs across multiple platforms, and in the process has to test and try to use many of them - in doing so learned a lot about how hard it must be to develop them (basic usability, speed for normal cases, etc).
Anyway, you can see the bots for what would be considered the first class platforms at: https://build.webkit.org/#/
You can see many linux bots running - though it looks like Qt bots aren’t there any more, I don’t know if that means they’ve moved to chromium or what. These also aren’t the chromium model of “we provide the entire UI and basically the application as well”, they’re the ports that permit platform native WebKit integration - platform native controls, etc. So while the original webkit approach was BS, it’s much better now: it’s been set up like this for well over a decade at this point.
I do think as time went by the JIT backends for a few architectures went away - largely because the engineering time required by those platforms vs. the real world usage was not warranted by those companies[1], but to this day the webkit project continues to support multiple linux backends, and at least in the past there was a general policy of trying to ensure other platforms were not broken by changes or that you’d try to fix them when possible (sometimes it’s not possible due to lack of local setup - but the old hilariously customized bugzilla instance was integrated with build bots for many of the platforms so you could identify and fix breakages before committing).
Now to be clear I haven’t really been directly involved in WebKit for a long time (maybe a decade?) as it really started my platform security trajectory (I started focusing on security and secure architecture while trying to make WebKit more robust in the face of endless weekends consumed by CVEs, but slowly realized fixing bugs in webkit was moot if there were problems in the lower layers. Now I work on compiler level platform support and mitigation.)
[1] SH4 especially I think was a Toshiba architecture that was used in the dreamcast I think? but I think at this point it’s been largely abandoned (maybe displaced by risc5? - I’m kind of surprised JSC doesn’t have a RISC5 jit backend yet but I guess people only care about V8, because most platforms just use chromium there does appear to be at least some risc-v support: https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/assembler/MacroAssemblerRISCV64.h – JSC’s MacroAssembler is the abstraction interface it uses in the backend, I used to work on and with it, but it’s obviously significantly more complex now that what it was back in my day </old man>)
integrate it directly into the browser engine and replace all of the internal data structures with the more robust mechanisms of the browser itself
libxml2/libxslt are not used only in browsers, they are used in other software as well. Just like, eg, SQLite. So, it doesn’t make sense for the libxml2/libxslt maintainer to strip out its internals and replace them with browser engine internals (which browser engine, btw? Chrome? Firefox?). If browser vendors wanted to do that, they of course are welcome to 🤷♂️
That was my point: if xslt and xpath were considered critical, the long term browser path would be migration from libxml, etc - not supporting them.
The usage environment for libxml in general is not the same as what browsers have to consider.
It was the Chrome team that said resources were limited 🤷
yes, as in “there are only so many people available”
Having money does not change that: you cannot simply add people.
I want to be clear: I really really dislike chrome, and hate google, and I am saying I’m siding with google here.
This is not a matter of having large amounts of money, it’s a matter of having enough engineers, but there’s a limit on how many engineers you can have working on something, and if you could have more engineers would you really want to have them working on a niche API that is extremely complex and hard to implement? Or would you prefer them to work on things that people actually use? like emojis. :D (More seriously css or js features that every website uses)
It’s kind of annoyingly from my PoV wasm does make things like sites having embedded xslt implementations an option (page load latency and perf), but if those became popular, then much like JSON. browsers would care about perf, etc - but xslt is not popular despite having been available for decades - I was complaining about it existing and trying to kill it, or at least xpath decades ago due to the performance and security problems.
I disagree about arguing by comparing the total budget of an arbitrary parent entity with the budget given to a specific issue.
There are unconceivably many issues that they could spend their money on.
A much more valid argument would be to point out what issue they are spending their money on that costs more and is less important. Doesn’t seem like a high bar.
Google chose to spent money and engineer time on breaking libxslt and trying to remove XSLT from web standards and Google Chrome. They could have spent it on fixing the bugs instead, or on helping the libxslt maintainer who they rely on but don’t pay.
Whataboutery is a rude way to argue. When people are complaining that Google are spending time and money to wreck XSLT, it’s insulting to say “what should they do instead, fix world hunger?!” No! Don’t derail the conversation. Google made a mess they need to clean up. You are suggesting they should fuck off to do something else instead.
feel free to disagree.
but please don’t interpret what I write widely. I didn’t suggest anything about fucking off. you also don’t get to make the rules about what is rude.
That said, I am sorry that it railed you up, definitely not worth it.
I just made an abstract comment about the argument structure, not the content. meta, if you will.
You are clearly a little upset. But I feel like it’s important to point out that Google did not make a mess. Even though the mess wasn’t created by them they did encounter it in their work and removing xslt 1.0 support is in fact one way to clean up that mess.
I feel like it’s important to point out that Google did not make a mess
Why? Does Google pay you or something?
I don’t understand: Google ships Chrome, and should be responsible for Chrome, but somehow you think they can ship Chrome and not be responsible for it? Bananas.
they did encounter it in their work …
If by encounter you mean directly fund breaking it.
Google is why libxslt’s maintainer burned out because it is Google is who wasted their time.
Mozilla doesn’t use libxslt; Google could switch to Mozilla’s libxslt, or write their own, or leverage that fancy sandboxing they put so much effort into, but they instead chose this.
Why? Does Google pay you or something?
Because I think the truth is important.
I don’t understand: Google ships Chrome, and should be responsible for Chrome, but somehow you think they can ship Chrome and not be responsible for it? Bananas.
I can’t see where I suggested or hinted that they should not be responsible for Chrome in my post. Perhaps you can explain how you got there?
If by encounter you mean directly fund breaking it.
It was broken without them funding discovering the breakage. The maintainer burnt out because the library is unmaintainable and it’s not clear that it should be maintained. The bugs weren’t created by Google merely reported. There are only a few actions that Google could take here:
All of them are completely legitimate ways to handle this problem. They in fact did try to fix bugs in the package and ran into the exact same issues that likely led to burning out the maintainer. The fact is that the xslt feature does not pull it’s own weight and none of the browser developers want to keep pooring money into it. Not Mozilla with their own package with it’s own issues they have to deal with. Not Apple with Safari. Not Microsoft with Edge and Not Google wiith Chrome. You may not like this fact but there are simply not enough users to warrant supporting something with as many issues as XSLT has. Dropping it is the sanest decision you can make here.
It was broken without them funding discovering the breakage.
“It” in this case, is the use of libxslt that Google included in Chrome. It is not anything else, and it is nobody elses responsibility but Google that there is a bug there, even if someone else originally wrote some of the code.
I can’t see where I suggested or hinted that they should not be responsible for Chrome in my post
Okay, maybe try and read it again, because to me it sounds a lot like you think bugs referred to here shipped in Chrome are somehow the libxslt-developers’ responsibility.
All of them are completely legitimate ways to handle this problem
Legitimate as in legal? I’m not so sure. I think this might be an antitrust violation, but I’m not an expert in that. But maybe you mean “legitimate” in that I’m not allowed to be unhappy about Google doing it. I don’t understand that at all – who the fuck do you think you are to tell me what I or anyone else can be unhappy about?
Do you not care that Google previously made multiple repeated claims that they weren’t going to break the web? That they even gave numbers explaining what thresholds were being considered:
https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0
Dropping it is the sanest decision you can make here.
I cannot speak to their mental health and neither can you. I am not insane for thinking there is a lot fishy about this. I am not insane for being annoyed that Google can promise not to break my 20 year old programs and then ask what if. And I am sorry to press you to answer this again:
I feel like it’s important to point out that Google did not make a mess
Why? Does Google pay you or something?
Because I think the truth is important.
It’s not true. Google did create Chrome and are responsible for everything in it, including their choice to use libxslt. Google did promise to support features in-use, and the truth is that Google is breaking those promises and you – who do not as near as I can tell have a stake in this, are trying to convince me and others that this behaviour is acceptable to you and should be acceptable to me too.
So I want to know why exactly you are doing that.
You have every right to disagree with their decisions. I have every right to agree with them. If I were them I would make the same decisions. I’ll not continue this since it seems to really set you off.
But in essense it’s the same thing. Budgeting is decided by the parent entity and so is prioritisation of work. Be it “no resources for XSLT” or “we’re pushing this new feature no one (but parent entity) asked for”, either way it’s decided by the parent entity.
We all know that Google has so much money that adding one or two engineers to work specifically on XSLT would have no impact on their bottom line whatsoever. The expense is comparable to impact of a poorly worded press release or a random rumour.
I don’t agree. They have a lot of money but also a lot to spend it on. So the total amount of money is not supporting any argument.
Should they use it towards feeding people? Creating a new product? Pay their employees even better? Save the profit and pay dividends? Difficult to decide.
BTW, I don’t have an opinion whether they should spend money on this. But if they should, for other reasons. Otherwise, you could argue that goverments with big budgets should solve all problems…
Should they use it towards feeding people? Creating a new product? Pay their employees even better? Save the profit and pay dividends? Difficult to decide.
Sorry, what are you asking of folks here? To come up with a new budget proposal for Google? That’s a ridiculously high bar for criticism. Google doesn’t prioritize the web platform anymore, that’s about as much feedback as is necessary in this context.
I think I must have put it confusingly, at least the argument is not going into a very productive direction. Sorry for that.
To come up with a new budget proposal for Google? That’s a ridiculously high bar for criticism.
That is kind of my point, having trouble to bring it across. If you bring up the net sum of the budget, you make the argument in my view about the whole budget. Without that context, the same number can mean very different things. I fail to see how mentioning it furthers the argument.
From the parent:
We all know that Google has so much money that adding one or two engineers to work specifically on XSLT would have no impact on their bottom line whatsoever.
That is true only in isolation. If they would make all their decisions with a “one or two engineers don’t matter”, it will matter. And I think they have to “make” many decisions.
I think what is emotionally troublesome for me is that they profited from libxslt freely and caused the maintainer even more work. (if I got it right)
But you can make the point differently, of course, even budget oriented but it would be much easier to argue about smaller parts: e.g. investing in making XSLT solid is more or less important than other things that they DO invest in.
I don’t agree. They have a lot of money but also a lot to spend it on. So the total amount of money is not supporting any argument.
This is nonsense. It’s a big company. Big companies work by slashing and burning their internal teams until something goes wrong, then pouring money onto those fires that they created. Typical established products at big tech companies run 99%+ margins, and the money from that is mainly dished out to executives, stock buy-backs, and acquisitions of companies that can feed the demand for future “established products”.
My team at (REDACTED) with 98%+ margins grew its revenues by $400+ million in 24 months, to $2.5 billion, and the result was: I got to chop my headcount by only 40%! This is how large companies operate. My boss from that company is now a CEO at G****e making similar cuts there.
The criticism is targeted towards the entity that makes these budgeting decisions, not an “arbitrary” one.
I don’t mind critisizing Google at all! It is just about how.
I disagree about arguing by comparing the total budget of an arbitrary parent entity with the budget given to a specific issue.
arbitrary parent in the set organisational super structures: chrome team, their org, Google, Alphabet, …
Thanks, I came here to say mostly the same thing and you saved me the effort. :) A lot of straw arguments like this can be deflected by asking “why is this my problem?” If google has trillions of dollars but doesn’t feel like allocating any of them to upgrading its infrastructure, then that is a google problem, not a problem that can be projected out into the wider world on us.
The problem appeared because most browsers killed RSS, so website owners started to use XSLT to display a styled feed. The browser vendors should either return RSS support or leave XSLT as-is.
Mason mentioned that they didn’t have resources to put toward updating their XSLT code, and got widely derided for it. “Google has trillions of dollars!” people hooted. Google has trillions of dollars. The Chrome team very much does not. They probably get, at best, a tiny fraction of one percent of those dollars. Whether Google should give the Chrome team more money is essentially irrelevant, because that’s not in the Chrome team’s control. They have what they have, in terms of head count and time, and have to decide how those entirely finite resources are best spent.
Well maybe they should be forced to sell Chrome to a company that prioritizes it
As a side-issue, out of curiosity, are any lobsters doing or seen anything cool with XSLT?
each atom blog or podcast feed that doesn’t look like crap in-browser is result of XSLT styling.
I’ve seen this referenced a few times, but do many people actually do this? What I more typically see is that the same data is used on the backend to render both an (unstyled) XML document and a human-readable HTML/CSS/etc landing page, and the HTML page then references the feed using a <link> element. I don’t think I’ve ever seen a styled XML sheet in the wild (I’m sure they exist, just very rare). I’m not even sure I’d want to implement a website in that way - it seems much easier to generate two different views from a single internal data source than generate a single XML view that is in turned used to generate an HTML view (and potentially a JSON view or other output formats depending on which standards I’m using for my data).
The point is not to generate the main blog page from RSS, but to prevent displaying RSS as an unformatted XML document when you click on the RSS link in your browser. I use XSLT for the RSS feed on my website for this reason, too.
I do just want to point out that, HTTP has provisions for a client to specify what content it wants to see through the Accept header, which is correctly set for browsers, and would be a reliable way to achieve a “styled RSS feed”, just by delivering HTML only to clients that request that.
Why is that a thing you need to prevent? I wouldn’t expect that to be the case for a JSON file I opened in my browser. Isn’t the RSS feed designed to be a machine-readable format?
Because we don’t point end users at JSON files, we point them to RSS files and tell them to ‘add this URL to your feed reader’, so naturally they might end up clicking on the link and we don’t want them to end up seeing a mass of XML text. So we style it so that humans can understand it.
Speaking for myself, I’ve never bothered styling any XML feeds I’ve published.
If you’re not familiar with feed readers, it might be confusing to see the exact same content both in the canonical “blog” form, and as a separate file with maybe different styling.
Any competent feed reader will be able to extract the feed URLs from the main page headers anyway.
If I published a style RSS feed, I wouldn’t actually publish the same index in a separate web page, that would just be duplication.
I mean, jsonfeed exists and doesn’t seem to have had this issue, as do various calendar sharing conventions and other tools. And as I pointed out before, you’ve also got discovery directly from HTML - most of the feed readers I’ve ever used can accept a link to a bog standard HTML homepage and extract a list of all the relevant feeds a user might be interested in. And if none of that works, HTTP has supported content negotiation for a very long time now indeed.
I can somewhat see the value of an XML->* conversion tool, in the same way that my blog is built as a markdown+filesystem->html conversion tool. But I don’t quite see why that conversion has to take place inside the browser. I suspect if someone proposed this feature today, it would be very quickly rejected as an unnecessary feature in the same way that a built-in markdown renderer doesn’t make sense for a browser.
jsonfeed exists and doesn’t seem to have had this issue,
If RSS is niche, then jsonfeed is surely a niche of a niche. If approximately ~no one uses it, how do we know there’s no issue?
I don’t quite see why that conversion has to take place inside the browser
Because then you don’t have to host a bunch of extra pages on the server, you can just host the source XML and a stylesheet and minimize your hosting needs.
If RSS is niche, then jsonfeed is surely a niche of a niche. If approximately ~no one uses it, how do we know there’s no issue?
And the other examples?
Because then you don’t have to host a bunch of extra pages on the server, you can just host the source XML and a stylesheet and minimize your hosting needs.
But isn’t that true for a bunch of other features? Like I said, why am I having to host a bunch of extra HTML pages when the browser could just be rendering my markdown for me? I don’t think browsers have ever been in the “minimizing your hosting needs” game.
Because we don’t point end users at JSON files, we point them to RSS files
The existence of JSON Feed—an RSS/Atom successor that uses JSON instead of XML—makes this increasingly untrue.
I’m not sure how anyone thought a JSON feed would be a good idea. JSON can’t be parsed while streaming so a feed can only be rendered once it is fully loaded. In comparison a browser can render XML while it is still being streamed…
I’ve had success streaming JSON in Python projects using both ijson and Jiter: https://simonwillison.net/2024/Sep/22/jiter/
I’ve seen that example given recently (Eric Meyer’s blog follow up I think) and I think I’ve been tried it myself 20 years ago but I can’t think of a single case of stumbling into this on the web.
The small haiku collection on my website is made with XSLT. The raw XML is at poems.xml and the style is at index.xsl. It’s statically generated though using XMLStarlet, so the browser doesn’t apply it:
index.html: index.xsl poems.xml
xml tr $^ > $@
I used XSLT every day back in 2010–12. I worked on the frontend for a social network for TV and movies that used XSLT to transform XML coming from the backend. The backend had different endpoints that returned XML for profile details, activity history, friend stream, yadda yadda, and so we used PHP to stitch everything together into a single XML document and then XSLT to transform that into HTML. I’ve been afflicted with a fondness for it ever since.
I made a plain text / RSS focused blog “engine” a while back:
The feed.xml can be viewed directly in browser: https://shinobi.btxx.org/feed.xml
as a result of all this, I now strongly believe that every proposed-removal issue should point to the process and where the issue stands in it. (And write down the process if it hasn’t been already.)
I think that’s a great idea.