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

Source of specs? #1

Closed
j-f1 opened this issue Sep 20, 2020 · 6 comments
Closed

Source of specs? #1

j-f1 opened this issue Sep 20, 2020 · 6 comments

Comments

@j-f1
Copy link
Member

j-f1 commented Sep 20, 2020

@MaxDesiatov

With Tokamak you'll have to use the Fetch API, and there are no SwiftWasm bindings for it yet, as far as I'm aware. I guess we will have some in the near future as a part of the DOMKit library, but my understanding is that it's not there yet, and is not a part of WebIDL declarations included there, maybe @j-f1 could clarify? Also, bear in mind that fetch returns a Promise object, and the API for it is still being developed in swiftwasm/JavaScriptKit#62. Closure-based APIs in SwiftWasm are not very trivial to work with, as you have to be aware of the lifetime of your closure instances and manually release them. This is an inherent problem caused by the differences in how JavaScript (garbage collection) and Swift (reference counting) allocate memory for closures and their context.

@j-f1

Indeed — fetch is a separate spec that would have to be integrated. I’m not sure how the original maintainers got the .webidl files out of the specs, and I would like to follow the same process for fetch.

@MaxDesiatov

Yes, it would be great to know where the WebIDL specs come from, as I'd like many more APIs covered eventually, IndexedDB, WebGL (WebIDL for this one is maintained together with the human readable text spec apparently), Web Animations obviously, and whatever comes next that users would be interested in.

I’m guessing they were extracted from the .bs files by looking for the <pre class=idl> blocks. @Unkaputtbar @PSchmiedmayer do you have any more information on how this was done?

@mjburghard
Copy link

I looked up the WebIDL specs through the MDN web docs. The specification sections of a Web API usually links to the official specification. Then I just copied the specification into a .webidl file, .e.g. https://developer.mozilla.org/en-US/docs/Web/API/EventTarget and https://dom.spec.whatwg.org/#interface-eventtarget.
Browsers also may have WebIDL files in their repositories.

@j-f1
Copy link
Member Author

j-f1 commented Sep 20, 2020

OK great, so there wasn’t an automated tool I was missing. I’ll see if I can code one up!

@j-f1
Copy link
Member Author

j-f1 commented Sep 20, 2020

Done: https://github.com/j-f1/bs-to-idl

@j-f1
Copy link
Member Author

j-f1 commented Sep 20, 2020

alright, I’ve got things mostly working now, although I need to find a way to parse the html spec, where several important things are defined, but is formatted with HTML tags inside the code.

Error: The following types are undefined:
	- AbstractWorker
	- CacheQueryOptions
	- ClientQueryOptions
	- ClientType
	- EventHandler
	- ExtendableEventInit
	- ExtendableMessageEventInit
	- FetchEventInit
	- HTMLFormElement
	- HTMLSlotElement
	- MessagePort
	- PostMessageOptions
	- RegistrationOptions
	- VisibilityState
	- WorkerGlobalScope
	- XMLDocument

@MaxDesiatov
Copy link
Contributor

I guess this can be closed as outdated, right?

@j-f1
Copy link
Member Author

j-f1 commented May 3, 2022

Yep, so glad that webidl2 exists!

@j-f1 j-f1 closed this as completed May 3, 2022
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