dom

dom copied to clipboard

See https://wiki.whatwg.org/wiki/DOM_XSLTProcessor. Per https://github.com/whatwg/html/pull/738 this is implemented in all browsers now.

These are the surface-level differences between Gecko and Blink that I added as TODOs in our IDL file:

• In Gecko, the transformTo*() methods throw an exception in case of error, while Blink returns null.
• In Gecko, it's possible to set and get back any parameter value, not just DOMString.

For the error handling, I think it probably doesn't matter much for compat if we return null or throw an exception. For parameter values, supporting any value type would be slightly more code, and since it's apparently not needed for compat I think just DOMString would be better.

This is the use counter data for Chrome:

• <?xml-stylesheet type="..." href="..." ?> in markup causing the document to be transformed using XSLT
• new XSLTProcessor in script

Both are so low that there's a good chance for some simplification if this is spec'd from scratch.

I've sent https://github.com/whatwg/dom/pull/972 to define just the XSLTProcessor interface, pointing back to this issue.

I went ahead and queried HTTP Archive for "new XSLTProcessor" to see what current usage looks like, and put the results in https://gist.github.com/foolip/d59bd1ab27b2c93a1a37b434074ea410.

It's "only" 7-8k sites, but my sense is that this is going to be found in more "enterprise-y" sites and that it's stuff nobody is around to maintain any longer. https://affiliates.skrill.com/includes/scripts/xmlxsl.js is a good example, where if that code is actually used (not checked) all modern browsers would go down the TransformXML_Moz path and break at the new XSLTProcessor() call.

I also looked up sites that trigger Chrome's use counter, at looked at https://www.athome.co.jp/ as a sample. I did delete window.XSLTProcessor and the result at the bottom of the page is:

But it should look like this:

Since it seems relatively easy to find things that will break, I'm not very optimistic about getting rid of XSLT from the platform. I think at the very least a drop-in JavaScript implementation of XSLTProcessor would be needed to help people transition, and that's a lot of work...

Since I formatted it nicely in https://github.com/web-platform-tests/wpt/pull/28639, I'll repeat it here. Additional details on XSLT in HTML:

• Interactions with XPath and XSLT
• Interaction of script elements and XSLT (non-normative)
• Interaction of template elements with XSLT and XPath (non-normative)