If I, and others, could easily find such examples, I believe browser vendors could easily find these, too.
I would like @mfreed7 @domenic and other Googlers who initiated and move on with this proposal to acknowledge this, and provide more rationale for removing XSLT than just Chrome Status counter stats.

Thanks for raising these 6 examples of sites publishing XML files. We can add it to the existing list of 357 sites already identified by other browser vendors on the main XSLT thread. I'm not sure we need a special issue discussing these particular 6, unless they're more important for some reason.

As you pointed out, the criteria for removing something from the web isn't that "nobody is using it". The web is a big place, and that would make it impossible to ever remove anything. The criteria is that a) only a very small percentage of people/sites will be affected, b) there are ways to mitigate the breakage for even that small group, and c) there's a reason to want to remove the feature. I believe all of those are true for XSLT, and I've provided supporting data on the other issue.

I've already looked into the first link (on congress.gov) a few days ago, and while it's true that legislative text is published in XML, that's not the primary link that most people use to access the text of legislation. Indeed, do a web search for "H. R. 3617" and the top link goes to a nicely formatted HTML page meant for people to read. On that page (if you dig pretty far - click Text in the middle, then click "XML/HTML"), you can find the link to that XML file. I don't run the congress.gov site, so I don't have data, but I'd be willing to bet that the XML link isn't clicked very often by humans, at least on purpose. XML is for machines to read, and we're not proposing to break that in any way.

Since this new issue seems like a duplicate of the other one, I'd be supportive of closing it.

I believe all of those are true for XSLT, and I've provided supporting data on the other issue.

The problem is: we need more than just belief.

1. There's no public record for the decision. The only publicly available discussion you linked to clearly states that the numbers are not low enough, people will object to this decision, and that the discussion should be postponed. There's no investigation into the long tail of web sites, of how many exactly would be broken etc.

2. The discussion in Should we remove XSLT from the web platform? #11523 clearly showed that you had no idea about the existing use cases for XSLT. See, for example, this comment.

Any superficial research into "just 357" sites happened after people had objected.

3. Given the fact that you have access to a vast trove of Chrome data, and I only did very light research, I still found 6 sites you missed. How many sites from the long tail did you miss? Just these six? Or significantly more? Can we dismiss all of them with "oh, it's just for machines"?

It means that there was literally no investigation before proceeding with this beyond looking at chrome counter stats:

• There's no public record for the decision
• Use cases for XSLT are trivially discovered, but had to be pointed out in the discussion
• It's trivial to find numerous web sites (including governmental and regulatory) that rely on XSLT that you missed

To quote Blink principles of web compatibility again:

First and foremost we have a responsibility to users of Chromium-based browsers to ensure they can expect the web at large to continue to work correctly.

seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!

This change breaks 0.04-0.1% of page views (does this count all usages, not just usages from Javascript?). And yet, the whole process seems to be:

• "here are counter stats"
• "you can always use this polyfill/browser extension that I developed in half a day"
• "good work, remove"

Even in your reply you keep saying things like "I believe all of those are true for XSLT", "I don't have data, but I'd be willing to bet that the XML link isn't clicked very often by humans".

Shouldn't the standard for removing a feature from the browser more rigorous than that?

I've already looked into the first link (on congress.gov) a few days ago

Again, this is just another data point against removal. Why did you only look into this a couple of days ago after someone pointed it out in the discussion, and not three weeks ago when the original discussion was started?

It means that this entire decision is rushed, and based on gut feelings, not hard data.

I'm definitely not trying to sound dismissive here, I appreciate your feedback... At the same time, I would like to add that WHATWG has a stages model and if you look at #11523 it is currently stage 1. The things that are being done now are to take it to stage 2. I'm not saying it's a model for anything but it's worth noting that there are other removals that took a very long time, including over a decade. It's very possible or maybe even plausible that we will gain new information along the way, that also is part of the process imo. I'm just saying, I don't believe there isn't a "decision" made here in the way that's suggested.

At the same time, I would like to add that WHATWG has a stages model and if you look at #11523 it is currently stage 1.

+1 to this. One issue is that there are a lot of incorrect assumptions being made (e.g. I'm the only one involved, the decision has already been made, etc). The whole point of the other issue (the one titled "Should we remove XSLT from the web platform?") was to discuss. That's why it was phrased as a question. It's great that some examples and discussion were posted before the thread had to get shut down due to ad hominem attacks. I don't purport to be an expert on all things, which is why I value the (non-ad-hominem) feedback. (E.g. see this comment or my others.)

It means that this entire decision is rushed, and based on gut feelings, not hard data.

Again, there's no decision yet, just a discussion. Thank you for the six example sites here - that's helpful and I'll take a look.

@bkardell

The stages process is mostly about adding features, not removing them.

In any case, here's a description of Stage 1:

A comprehensive explainer
Consensus that the WHATWG is interested in exploring solutions in this problem space

And there's a link to the expected explainer format, too: https://w3ctag.github.io/explainer-explainer/#introduction

Link to venues where readers can discuss this proposal.
Describe the problem that your proposed feature aims to solve from an end-user’s perspective.
Describe other ways the problem might be solved and why you prefer your proposal.

1. This looks has already immediately moved into Stage 3-Stage 4: Remove mentions of XSLT from the html spec #11563 and work already started on removal in Chrome: https://issues.chromium.org/issues/435623334
2. The consensus we've seen was: "the numbers are not low enough, there will be objections" in the only discussion linked and perhaps a "webkit is cautiously supportive" in the discussion.
3. For removal the explainer should include more than just "our counter shows a decline". I can point to numerous APIs released by Chrome that hover around the same mark and arguably represent much more complex specs and larger areas of attack than XSLT.

All I'm asking for is actually showing diligence when removing features from the web.

@mfreed7

Again, there's no decision yet, just a discussion.

The problem is optics.

If it's "just a discussion", then for an external observer there are immediate questions

• why is there a already a PR to remove this from HTML?
• why has Chrome already started working on removing the feature from the browser?
• why are obvious and easily discoverable use-cases of this feature have to be pointed out by the community that may not even be aware that this is happening, and not by the people who hold all the data in the world?

As an offtopic: the stages model does not work for feature removal.

• why is there a already a PR to remove this from HTML?

Because that's required by the stages process, as a starting point. It helps people see what's being proposed concretely.

• why has Chrome already started working on removing the feature from the browser?

To explore the effects of removal. It's hard to tell what will break without being able to turn it off and see.

• why are obvious and easily discoverable use-cases of this feature have to be pointed out by the community that may not even be aware that this is happening, and not by the people who hold all the data in the world?

Because the examples that matter the most are the ones brought up by the community. E.g. this issue lists several XML feeds that are (apparently?) important to you. We like to look at a lot of data and not jump to ill-informed conclusions, or assume we know everything before proposing a question for discussion.

As an offtopic: the stages model does not work for feature removal.

Fair - it's not often that features are removed from the web, and that's a good thing.

As an offtopic: the stages model does not work for feature removal.

This would be an interesting issue because I agree that it currently requires some interpretation.. It might be nice to fix that. I agree with your statement that there is a problem with optics here and it would be great to figure out how we can help that work better. I'm not saying "then there would be no disagreements" but it would be nice to avoid some of the kinds of things that occasionally happen where there are a lot of misunderstandings. For example, this is also why some of the intents were added/renamed in the blink process - but it's still not always clear. I'm not sure how to do better, but there's constant efforts (we probably shouldn't discuss it in this issue).

@mfreed7 @bkardell Fair enough :) 👍

unless they're more important for some reason.

@mfreed7 Government sites might not adapt just like commercial ones due to lack of market pressure and therefore users will need to install third party spammy extensions from the web store, unless a particular extension will be offered with just one click.

I remember these sites relying on flash and I believe it'd be more secure to implement something in JS rather than force people to look at insecure alternatives.

Generally it feels like the issue with XSLT is the implementation itself and not with the standard itself (like.. why was the implementation argument even considered on-topic in context of removing XLST from the standards?), albeit I agree that XSLT 1.0 is outdated, that's why I'd support browsers securely implementing newer versions.

As I'm looking through sites that use XSLT, I'm coming back here to talk about the specific 6 sites listed in the OP. Here's what I found:

So two of them (#4 and #6) are really not meant for humans, other than the XML developers using the XML feed. The other four are primarily XML feeds (for machine usage) that have XSLT so they they're readable by humans who accidentally click on an XML link. In all four cases, a quick web search for the same information turns up the equivalent HTML pages that are meant for humans. In none of those web searches did the XML feed itself show up in search results, at least that I saw. And in all four cases, the equivalent HTML page that is meant for humans is significantly richer than the beautified XML feed. More information, lots of interactive controls to drill down, graphics, etc.

So yes, these government sites are indeed publishing data via XML, and that can certainly continue uninterrupted. Nothing about the XSLT removal proposal will affect XML publishing. It will affect human users who (for whatever reason) click on a published link to the XML file. The same happens today for visible links to JSON feeds - they are displayed in the browser as raw JSON. Based on that, my conclusion is that humans will not be affected (in these 6 cases) by a removal of XSLT. If you disagree with that conclusion, please be specific about the use case that breaks if XSLT is removed.

I love how opening up the XML links results in a page without any ads, trackers, pop-ups, or other attention-draining distractions. A super refreshing experience that I prefer to preserve if possible.

The issue should be renamed to "XSLT removal will reduce rendering quality on 2 additional URLs when visited by a browser." The sites will continue to work, and work well for seemingly all interactive use cases in browsers.

I love how opening up the XML links results in a page without any ads, trackers, pop-ups, or other attention-draining distractions. A super refreshing experience that I prefer to preserve if possible.

But the XSLT-transformed-to-HTML pages could easily include all of those things also, right? I.e. that was just a choice of whomever built the particular XML and HTML sites. They could just as easily swapped those things, so the XML has ads and the HTML doesn't. Keeping XSLT around just because one site chose not to put ads on their (presumably much-less visited) XML feeds doesn't seem like a very convincing argument, at least to me.

As I'm looking through sites that use XSLT, I'm coming back here to talk about the specific 6 sites listed in the OP. Here's what I found:

URL Purpose HTML site found in search
1 congress.gov Beautified XML feed Equivalent (better) link

Looking at the congress link, there are 4 ways of consuming the text.

The default display has a lot of features that suit short term use cases such as sharing or discussing a specific paragraph, however, it limits the width of the text, is noticeably laggy even on a high end computer, has a constantly distracting highlighting when moving the mouse/scrolling, search hits the entire page instead of the actual content.

The XML view on the other hand is far superior as a document to spend a long time with, I regularly have that kind of document open for weeks/or months at a time as a reference documentation.

The text view is awful but readable.

The PDF view is unusable to the point of being an absolute joke, maybe lets remove PDF from chrome, the attack vector is probably 1000x the size of XSLT anyway ;) .

However, my opinion is being made from a position of ignorance. The best way to work out how people are using these documents and how this will impact them is to have actual conversations with people that regularly interact with these systems. Speculation about how a process you are unfamiliar with works/is used is rarely accurate. Ignorance is a dangerous source of confidence.

@mfreed7

1. It's not "just 6 websites". It's six websites that I found without much effort, and without having your access to vast troves of data that Chrome provides, and that you still missed. And that's besides all the other use cases people provided in the previous discussions.

2. "It will affect human users who (for whatever reason) click on a published link to the XML file." Indeed. Humans you completely dismiss because of your belief without any hard data.

Anyway. This is a lost cause. I'm withdrawing from this conversation. Chrome (primarily) will do what Chrome will do. After all, you don't get promotions for maintaining XSLT. You're paid for shoving multi-thousand-page specs against any objections, and have about as much (or less) usage as XSLT.

The XML view on the other hand is far superior as a document to spend a long time with, I regularly have that kind of document open for weeks/or months at a time as a reference documentation.

I see your points. I guess my point is just that these are all choices made by the congress.gov content editor. Both the display of the "beautified" XML version, and the other versions. The argument I think you're making is that because a few sites happen, today, to provide a view you like better, we should keep XSLT in the browser. What if, on the other hand, congress.gov decided to make the XML/XSLT view terrible, and you preferred the HTML version. Would you be here championing the removal of XSLT? If not, I think there's a flaw in your argument, right?

However, my opinion is being made from a position of ignorance. The best way to work out how people are using these documents and how this will impact them is to have actual conversations with people that regularly interact with these systems. Speculation about how a process you are unfamiliar with works/is used is rarely accurate. Ignorance is a dangerous source of confidence.

I opened a public issue specifically to ask the question about XSLT, precisely because I didn't know all of the use cases. I wanted to gather more data and feedback and see how it was being used, and also how we might (might!) be able to maintain existing use cases while removing the risks for all of the other users. I was able to pull together some of that feedback. But in doing so, I've endured all kinds of great comments, e.g. that I'm violently ignorant, that I'm the mouthpiece of a mafia cartel, and worse. Still, I endured that (and apparently continue to endure that) to try to have actual conversations about actual issues. But at this point I'm getting pretty tired of my actual words being completely ignored, and conspiracy theories being assumed in their place. The funny thing about all these theories - that I alone personally control the fate of the web - is that if they were true, I wouldn't have opened a public issue to discuss XSLT, and continued to respond on all of the others that sprang up. I would have just removed XSLT from Chrome and moved on. But Chrome doesn't work like that, and I don't work like that, so I am (still!) trying to do the right thing.

• It's not "just 6 websites". It's six websites that I found without much effort, and without having your access to vast troves of data that Chrome provides, and that you still missed. And that's besides all the other use cases people provided in the previous discussions.

It seems like your argument here is that until I've personally visited all of the sites on the internet, and reported the results back to you personally, then I can't form an informed opinion. If so, I don't think we're going to reach an agreement here. However, I did examine all of the sites, in detail, that you provided in the OP. Since you also said you're withdrawing from the conversation, we can close this issue.

shut it down guys, @mfreed7 needs his promotion

We use XSLT extensively

It seems like your argument here is that until I've personally visited all of the sites on the internet

No. Let me quote myself again:

The problem is: we need more than just belief.

1. There's no public record for the decision. The only Upcoming WHATNOT meeting on 2025-03-27 #11146 (comment) you linked to clearly states that the numbers are not low enough, people will object to this decision, and that the discussion should be postponed. There's no investigation into the long tail of web sites, of how many exactly would be broken etc.

2. The discussion in Should we remove XSLT from the web platform? #11523 clearly showed that you had no idea about the existing use cases for XSLT. See, for example, Should we remove XSLT from the web platform? #11523 (comment).

You started, and you continue being completely ignorant of where XSLT is used, and how. Literally the only data point you used was "Percentage of page loads over time". You didn't look at any data available to Chrome beyond that. You only started looking at anything after multiple people told you they use this, including on large sites, or on sites with many clients.

This is still dismissed as irrelevant.

To quote the literally one single publicly available discussion among browser vendors, emphasis mine:

dan: even if the data were accurate, not enough zeros for the usage to be low enough.
brian: I'm guessing people will have objections.

If we're pretending we care about usage numbers, complexity, security surface and not enough resources to deal with all of that, I can give more pointers as to where to look: all the WebKitchenSink "standards" added:

• MIDI at 0.0025%
• USB at 0.0011%
• Transport at 0.000175% (yes, that's three zeros)
• Bluetooth at 0.000009% (yes, that's 5 zeros)
• Serial which steadily grew to 0.000596% this year

If anyone were to suggest removing those, I'm sure, you'd be able to quickly find all the websites that could not live without them, and that couldn't use a polyfill, or a browser extension.

But now this has become an offtopic, XSLT will be removed, sites silently or not-so-silently will be broken, no one at Chrome will care since it's not a shiny new Chrome-only non-standard they have to push through against all objections.

The XML view on the other hand is far superior as a document to spend a long time with, I regularly have that kind of document open for weeks/or months at a time as a reference documentation.

I see your points. I guess my point is just that these are all choices made by the congress.gov content editor. Both the display of the "beautified" XML version, and the other versions. The argument I think you're making is that because a few sites happen, today, to provide a view you like better, we should keep XSLT in the browser. What if, on the other hand, congress.gov decided to make the XML/XSLT view terrible, and you preferred the HTML version. Would you be here championing the removal of XSLT? If not, I think there's a flaw in your argument, right?

Generally speaking I was trying to determine if what I was interacting with is a heavily used piece of infrastructure that is regularly used by a lot of people in an industry I'm not familiar with for a variety of use cases. My thoughts were overall a huge yes and that the primary way to use the document was through the XSLT, and while your reasoning for the HTML being a primary view is valid it feels like a photo editor developer saying the being the best way to view photos is in the photo editor because it's richer in features compared to a photo viewer. You should be actively trying to break your own ideas, explore cases that even slightly hint at there being something you're not considering, investigate them deeply and invite discussion, you shouldn't be quickly categorising the cases given to you, you should be having a conversation with someone who understands a specific case and understanding what it is, how they use it, what impact removing XSLT would have on them and drawing a conclusion based on that.

If the vast majority of implementations using XSLT could be categorised as actively bad or a box ticking exercise and the actual usage was tiny, then I might consider it, but taking on this kind of change means you actually need to take responsibility for it.

Generally on projects where I'm the creator of a piece of software other people depend on, the calculation I make is estimating how many man years of work it is to maintain XLST vs how many man years of work it is creating for other people. Ideally I put as much burden on myself as the creator as I'm the one responsible for making a breaking change I should bear the majority of the pain.

As for the rest of your comment. To put it simply, you come off as someone inexperienced, maybe I'm wrong and you have a big list of features you've successfully removed and public discussions you had in the process, if so, there's probably something to learn from those that's different here.

I think we are approaching the issue incorrectly. @dmitriid & @Pinteresting are making great technical arguments as to why XSLT shouldn't be removed. However, the issue is not a technical one but a political one.

The real reason for the removal is that Google, a profit seeking corporation, considers XSLT to be unprofitable.

Of course, they can't say this out loud, so they instead have @mfreed7 cherry-pick some numbers as justification.