Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define XSLTProcessor #181

Open
annevk opened this issue Feb 29, 2016 · 5 comments
Open

Define XSLTProcessor #181

annevk opened this issue Feb 29, 2016 · 5 comments

Comments

@annevk
Copy link
Member

annevk commented Feb 29, 2016

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

@foolip
Copy link
Member

foolip commented Feb 29, 2016

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.

@foolip
Copy link
Member

foolip commented Feb 29, 2016

This is the use counter data for Chrome:

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

@foolip
Copy link
Member

foolip commented Apr 16, 2021

I've sent #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.

@foolip
Copy link
Member

foolip commented Apr 16, 2021

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:
image

But it should look like this:
image

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

annevk pushed a commit that referenced this issue Apr 21, 2021
@foolip
Copy link
Member

foolip commented Apr 22, 2021

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

@whatwg whatwg deleted a comment Sep 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants
@foolip @annevk and others