Remove mentions of XSLT from the html spec

[mfreed7]

This PR removes all mention of XSLT in the html spec.

Closes #11523

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: crbug.com/435623334
  • Gecko: …
  • WebKit: …
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed: …
  Core documentation starts here: https://developer.mozilla.org/en-US/docs/Web/XML/XSLT
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/dom.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/references.html ( diff )
/scripting.html ( diff )

[gucci-on-fleek]

First, my apologies for commenting here; #11523 was (rightfully) locked while I was in the middle of composing this comment, but I didn't see any of these points mentioned elsewhere in that thread, so I'm adding it here.

---

1. Do any of your usage statistics show the age and “size” (popularity) of pages that use XSLT?

   Because if XSLT is mainly used by large commercial sites that are frequently updated, then deprecating the builtin support seems reasonable, since most of the sites will quickly update to include a polyfill. But if XSLT is mainly used by small personal sites that were last updated decades ago, then I wouldn't expect many of these sites to (ever) update, meaning that removing XSLT support would just mean that these sites will be broken forever.

   Given that XSLT has been supported since 1999 and its usage has been trending downwards, I suspect that the affected sites will mainly fall into the second category, meaning that the most likely outcome is site breakage rather than sites updating to use a polyfill.

2. Well-built web pages use progressive enhancement, so even if any particular JavaScript/CSS feature is broken/removed, the page should still continue to partially work. So if JavaScript support for XSLTProcessor() is removed, then at the worst, all the JavaScript on a page will be broken, but the rest of the page should still be usable.

   However, removing support for <?xml-stylesheet … ?> seems particularly problematic, because if that is no longer supported, then users will simply see raw, unformatted XML, which makes the page completely unusable for non-technical users.

3. Previous web platform deprecations have mainly affected JavaScript, and occasionally (or maybe never, I can't find any examples) CSS. Many legacy HTML features have been deprecated, but as far as I'm aware, all of them still work with all modern browsers. Some random examples:

   • <font>
   • align=
   • <xmp>

   So while previous removals may have broken complex/interactive web apps, or may have caused minor format/layout changes, nothing has outright removed features used by pure “documents” (as in things that you could print on paper). However, many traditional documents use <?xml-stylesheet … ?>, so its removal seems unprecedented. But I may be completely wrong here, so please feel free to correct me.

---

Personal note: I maintain a site that uses XSLTProcessor() interactively and that separately uses <?xml-stylesheet … ?> for RSS feeds; it would be slightly annoying if I had to add a polyfill, but I'd have no problem updating it before any browser changes are introduced, so no users will ever experience any breakage.

However, my main concern is for the “long tail” of the web—there's lots of vital information only available on random university/personal websites last updated before 2005, or are only available on the Internet Archive. Many of these sites use <?xml-stylesheet … ?> (and other obsolete features not discussed here like <frameset> and <font>), and it would be a real shame if these sites stopped working.

[nomis]

Some notable uses of XSLT that aren't for RSS:

• https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml
• https://www.govinfo.gov/content/pkg/BILLS-119hr400ih/xml/BILLS-119hr400ih.xml
• https://xmpp.org/extensions/xep-0182.xml

Personally, I'm using XSLT to transform complex XML data into multiple tables for viewing as HTML, so removing this functionality is frustrating. I'm also using it on microcontrollers where memory is limited (meaning that large HTTP responses need to be avoided) so that they only need to send a small dynamic XML document and the browser can transform it with a static immutable XSLT file into HTML. It's not practical to provide a polyfill that embeds the whole of libxml2 on a microcontroller webserver so this change would be forcing a re-implementation in JavaScript. Content that could be parsed independently as XML would become an opaque HTML document.

Page load stats don't necessarily indicate the quantity of existing content that could be accessed, and the number as a percentage of total page loads would be expected to go down over time given that adoption is hindered by web browsers only supporting XSLT 1.0 when there are features in XSLT 2.0 and later versions that would make it easier to use.

[jonsterling]

Thanks to @Zergy and @nomis for their useful comments on this PR. I feel that it is a bad idea to remove XSLT from the web platform at this time, and I chafe under the reality that it is large browser vendors who today decide what the "web platform" even is. Discussion of limited resources is moot, because the large browser vendors have effectively unlimited resources — which they are today using to snuff out important parts of the Open Web, redefining podcasts as YouTube channels, etc.

As you have seen in the other discussion prior to closing it and censoring a dozen on-topic comments written with care, there are a lot of very diverse ways that XSLT is being used to enrich the Web today. It's time to remember that the Web is all of us who publish websites. That's who ought to be deciding what is part of the "Web platform". I deeply love the World Wide Web, the creative and strange things that people put on there. Without lionising the problematic days of W3C, I wish that today's stewards of the Web came to it from a place of love for the platform and its history.

I sincerely encourage anyone looking at this page to decide for themselves whether my comment is off-topic or not. I think it is highly on-topic.

[domenic]

Nice, thanks for working on this! Don't forget to also update https://dom.spec.whatwg.org/#xslt at the same time.

[mfreed7]

Nice, thanks for working on this! Don't forget to also update https://dom.spec.whatwg.org/#xslt at the same time.

Yep, thanks for the reminder. I'll put up a PR for DOM also.