Kevin Gibbons

Ecma262 doesn't say anything about encoding of ES modules either. I think we can make at least the same assumptions that we use for testing imports of ES modules which...

Tests: https://github.com/tc39/test262/pull/4768

Looks good. I do wonder whether there ought to be a required MIME type, especially given that the other types all have one. If `type: "bytes"` had a similar requirement...

Good question. Looks like `type: "json"` imports are governed by `connect-src`, so I assume these should be as well. This will require filing a PR against CSP updating the ["Get...

`json` doesn't seem any more specific than `text` to me, really. It's just data either way.

Oh, nice, I didn't realize that it got exposed there and wasn't just editorial. In that case I agree `text` is fine, as long as we don't imagine later introducing...

@nicolo-ribaudo You might want to get in touch with @conrad-watt, who has done formalizations of other parts of the spec (specifically the memory model - https://arxiv.org/abs/2005.10554) in Coq.

If you want to know the history of changes to a repository, `git blame` is your friend (or for this repo you can use [searchfox](https://searchfox.org/ecma262/source/spec.html), linked from the readme). Have...

With regards to the example, the way a user is actually likely to run into this is more like ```js import { operation } from 'some-framework'; async function whatever(signal) {...

@jasnell There's no need to define a symbol-based protocol. The protocol for consumers can literally be "call `.addAbortCallback(yourCleanupFunction)`". That requires no other changes from WHATWG. (Though I agree that a...