-
Notifications
You must be signed in to change notification settings - Fork 44
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
browser-specs picking up multiple Wasm definitions #891
Comments
One of the reasons why the spec is in browser-specs is that the list of specs is used by MDN to link back to specs from MDN pages and The fact that the spec is a fork of the main JS API spec is explicit in browser-specs: the spec's Lines 6373 to 6386 in be53335
Both flags could be used to apply custom logic to that spec when it is considered for other purpose, and typically to filter its definitions out when building a cross-references database. The list only has this fork for the time being, but we're considering adding more of them in the future, see #529. We understand that these forks are meant to be merged back into the main spec (or abandoned). Monitoring them early on in browser-specs and Webref allows us to detect potential cross-spec issues (Web IDL, dfns, etc.) early on as well. |
Okay, I wasn't aware of the "fork" value for seriesComposition. I'll filter those out from Bikeshed. |
I believe this issue can now be closed |
Following up from this issue: WebAssembly/spec#1611
Only the official core/JS/Web specs should be picked up (https://webassembly.github.io/spec/js-api/#memory), as proposal specs (https://webassembly.github.io/exception-handling/js-api/#memory) will eventually be merged into the main spec branch. Ideally, no forks of the Wasm spec should be picked up to avoid linking to multiple, and potentially non-standard definitions.
The text was updated successfully, but these errors were encountered: