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

Provide XSLTProcessor #155

Closed
saschanaz opened this issue Mar 25, 2021 · 9 comments
Closed

Provide XSLTProcessor #155

saschanaz opened this issue Mar 25, 2021 · 9 comments

Comments

@saschanaz
Copy link
Member

https://wiki.whatwg.org/wiki/DOM_XSLTProcessor (whatwg/dom#181)

I think it's the only missing interface that doesn't belong to any real spec.

@foolip
Copy link
Member

foolip commented Mar 25, 2021

I've added this and a lot of other things which are implemented in one or more browsers in https://github.com/foolip/mdn-bcd-collector/tree/main/custom-idl. console.timeStamp() in console.idl is another example.

If there's a need for this non-standard IDL outside of mdn-bcd-collector, how about publishing it to a package similar to @webref/idl?

Putting it in webref would have certain benefits for maintaining it, but would also be a bit random. @dontcallmedom WDYT?

@saschanaz
Copy link
Member Author

saschanaz commented Mar 25, 2021

I somehow have considered the DOM wiki page as a semi-spec and just parsed it as ReSpec (it works as it has class=idl). Could we also do the same here?

@foolip
Copy link
Member

foolip commented Mar 25, 2021

I'm not sure, I don't think it belongs in browser-specs, but maybe it could be hacked in as an extra data source in Reffy?

How about all the other non-standard IDL though, is that not interesting, is it just XSLTProcessor you're missing now?

@saschanaz
Copy link
Member Author

Others are not widely implemented, so far this is the only missing one in types-web not filtered out by BCD support data when I remove all local IDLs.

@dontcallmedom
Copy link
Member

given that XSLTProcessor has a reasonably clear (if pretty slow) standardization path, I think maintaining it in webref as a patch with a link to whatwg/dom#181 would seem appropriate to me. I'm not convinced that parsing it out of the WHATWG wiki brings a lot of value (the only changes that I've happened in the wiki in the past 5 years where WebIDL-maintenance related), and it would likely break a lot of assumptions from a browser-spec perspective. If we want to avoid duplicating the maintenance until this lands in the DOM spec, we could get the WHATWG wiki to point to the webref patch.

I think the more general case of https://github.com/foolip/mdn-bcd-collector/tree/main/custom-idl would need more discussion - in particular, I don't think single-browser IDL customization should be added en masse to webref.

@foolip
Copy link
Member

foolip commented Mar 26, 2021

Maybe we should just send a PR to DOM to add the interfaces and algorithms that are just TODOs, pushing the problem one level down.

@saschanaz
Copy link
Member Author

Or opening a WICG repo? 🤔

@foolip
Copy link
Member

foolip commented Apr 21, 2021

I added it to DOM in whatwg/dom#972 so it should reach webref soon.

@dontcallmedom
Copy link
Member

https://github.com/w3c/webref/blob/master/ed/idlnames/XSLTProcessor.idl is in, should make it to the package tomorrow

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants