XSLT removal will break multiple government and regulatory sites across the world

[dmitriid]

What is the issue with the HTML Standard?

One of the issues we've seen in #11523 and #11563 is that the proposal to remove XSLT from the spec doesn't acknowledge existing use cases beyond Chrome Status counter stats.

According to Chrome's own Blink principles of web compatibility:

The primary signal we use is the fraction of page views impacted in Chrome, usually computed via Blink’s UseCounter UMA metrics. As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!

To add to the use cases already provided in the discussions above, here's a small list:

Name	Description	Link
United States Congress	Legislative texts are shown using XSLT	https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml and https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BILLS-119hr400ih.xml
National Weather Service Current Observations	Uses client-side XSLT to transform and display current weather observation data from XML.	https://www.weather.gov/xml/current_obs/KABE.xml
European Parliament Political Parties	Uses client-side XSLT to transform and display information on European political parties from XML.	https://www.europarl.europa.eu/politicalparties/index_en.xml
Therapeutic Goods Administration Code Definitions	Uses client-side XSLT to transform and display regulatory code definitions from XML.	https://apps.tga.gov.au/downloads/sequence-description.xml
Canadian Forest Service Weather Stations Metadata	Uses client-side XSLT to transform and display weather station metadata from XML.	https://cwfis.cfs.nrcan.gc.ca/downloads/fwi_obs/WeatherStations_CWFIS_export.xml
European Pollutant Release and Transfer Register Method Types	Uses client-side XSLT to transform and display method type codes from XML.	https://converters.eionet.europa.eu/xmlfile/EPRTR_MethodTypeCode_1.xml

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.

[mfreed7]

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.

[dmitriid]

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?

[dmitriid]

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.

[bkardell]

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.

[mfreed7]

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.

[dmitriid]

@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.

[dmitriid]

@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.

[mfreed7]

• 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.

[bkardell]

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).

[dmitriid]

@mfreed7 @bkardell Fair enough :) 👍

[zb3]

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.

[mfreed7]

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
2	weather.gov	Beautified XML feed	Equivalent (better) link
3	europarl.europa.eu	Beautified XML feed	Equivalent (better) link
4	tga.gov.au	Sequence description for the XML feed - not meant for humans at all	N/A
5	cwfis.cfs.nrcan.gc.ca	Beautified XML feed	Equivalent (better) link
6	eionet.europa.eu	Method type codes for the XML feed - not meant for humans at all	N/A

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.

[evanjrowley]

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.