-
Notifications
You must be signed in to change notification settings - Fork 440
Use latest IDL #816
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
Comments
From https://github.com/microsoft/TSJS-lib-generator#when-should-a-dom-api-be-included-here it sounds like the number of implementations is an important consideration. This unfortunately can't be determined on a per-spec basis as most specs contain some mature parts and some things yet to be implemented. Perhaps combining IDL with https://github.com/mdn/browser-compat-data would help here. I also wonder if it would help to have releases of reffy-reports that have certain guarantees, like all of the IDL being possible to parse with a given version of webidl2.js. |
Definitely a good-to-have, but I wonder what made you open this issue. Is this a blocker for anything? |
@github-actions close |
Closing because @saschanaz is one of the code-owners of this repository. |
From what I can see, this project extracts IDL fragments from W3C TR version of the W3C specs, when in most cases, the most uptodate view of what the IDL should be reside in editors draft.
In a separate project called Reffy, we have set up an automated extraction of the latest IDL fragment across a large number of W3C and WHATWG specs. That automatic extract is already used to feed automatically the Web-Platform-Tests repository of Web-browser test suites.
It may be interesting to take a similar approach here.
The text was updated successfully, but these errors were encountered: