Remove mentions of XSLT from the DOM spec

[mfreed7]

This goes along with whatwg/html#11563.

Closes #181.

• At least two implementers are interested (and none opposed):
  • Chromium - supportive
  • Gecko - supportive
  • WebKit - supportive
• Tests are written and can be reviewed and commented upon at:
  • https://chromium-review.googlesource.com/c/chromium/src/+/7027778
• Implementation bugs are filed:
  • Chromium: https://crbug.com/435623334
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1990759
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=300785
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

Corresponding HTML spec PR: whatwg/html#11563

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

---

💥 Error: 422 Unprocessable Entity 💥

PR Preview failed to build. (Last tried on Jul 3, 2026, 8:46 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build bikeshed/ReSpec specs

🔗 Related URL

Error output:

[
    {
        "lineNum": null,
        "messageType": "warning",
        "text": "Skipped generating some MDN panels, because the following IDs weren't present in the document. Use `Ignore MDN Failure` if this is expected.\n  #dom-xsltprocessor-xsltprocessor\n  #dom-xsltprocessor-clearparameters\n  #dom-xsltprocessor-getparameter\n  #dom-xsltprocessor-importstylesheet\n  #dom-xsltprocessor-removeparameter\n  #dom-xsltprocessor-reset\n  #dom-xsltprocessor-setparameter\n  #dom-xsltprocessor-transformtodocument\n  #dom-xsltprocessor-transformtofragment\n  #interface-xsltprocessor"
    },
    {
        "lineNum": null,
        "messageType": "failure",
        "text": "Did not generate, due to errors exceeding the allowed error level."
    }
]

This seems to be an issue with the Spec Generator service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can report the issue to the maintainers of Spec Generator directly. Please be courteous. Thank you!

If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can file an issue with PR Preview.

[mfreed7]

Seems extremely chilish for adults that work for a company as large as Google to keep locking threads where there are comments criticizing this push to drop XSLT, such as this issue and this pull request.

FYI: If you have to lock threads for there not to be opposition, you're probably the ones in the wrong. A discussion isn't "too heated" because people disagree with you.

So two things. One is that I haven't locked a single thread. Two is that others have (rightly) locked several threads because people kept making ad hominem attacks (like calling people "extremely childish") rather than focusing on the technical discussion. I've never seen a thread on WHATWG locked for disagreements - there are many examples of quite heated disagreements that are still open for comment. However, in those examples, the participants were able to talk about the merits of the technology being discussed, without disparaging the people making the comments.

[duckdotapk]

I do apologise if it was not actually you or any other user from Google who locked those threads, but, IMO, the point still stands that the person who did do so is acting in a manner that's actively hostile to having an open dialogue regarding a proposal that appears to be quite unpopular.

[mfreed7]

I do apologise if it was not actually you or any other user from Google who locked those threads

It wasn't me, but again, I appreciate that they did so.

IMO, the point still stands that the person who did do so is acting in a manner that's actively hostile to having an open dialogue regarding a proposal that appears to be quite unpopular.

On the contrary, it's unfortunate that the people who feel so passionate about this tech can't control themselves enough to act professionally and have a civil discussion. I want to understand actual use cases and try to mitigate issues, but now I can't hear from the subset of affected people who are able to carry on a conversation without name calling.

[annevk]

We should add the interface to the Historical section. That would more clearly indicate its status. Looks good otherwise.

[annevk]

Oh, and I guess we need to figure out how to deal with the MDN CI failures. Would that require first removing the incoming references from MDN @sideshowbarker?

[sideshowbarker]

Oh, and I guess we need to figure out how to deal with the MDN CI failures. Would that require first removing the incoming references from MDN @sideshowbarker?

Yeah, or else — based on what the error message at https://github.com/whatwg/dom/actions/runs/17081950335/job/48437853413?pr=1400#step:5:30 says, we could set the Ignore MDN Failure option to ignore the missing-ID problems.

(And to be clear, the only related consequence of those IDs going missing is that, in the margins next to places in the spec where those IDs occur, the MDN panels that’d otherwise show up there just no longer show up any more. In other words, it doesn’t otherwise break anything in any observable way — in particular, it doesn’t affect end-users/readers of the spec.)

[mfreed7]

We should add the interface to the Historical section. That would more clearly indicate its status.

Done.

Looks good otherwise.

Thanks!

Yeah, or else — based on what the error message at https://github.com/whatwg/dom/actions/runs/17081950335/job/48437853413?pr=1400#step:5:30 says, we could set the Ignore MDN Failure option to ignore the missing-ID problems.

Let me know if there's something I need to do within this PR, or if this should be separate. I don't know where the bikeshed options are configured.