Module type check should take environment into account

[annevk]

If module type is not "javascript", "css", or "json", then asynchronously complete this algorithm with null, and return.

We shouldn't claim to support "css" in workers here. That results in redundant fetches and is also inconsistent with the feature proposed in #7017.

(It also doesn't match the discussion in tc39/proposal-import-attributes#111 I think.)

cc @dandclark

[domenic]

Yeah, this is my bad for suggesting the IDL exposure-based check currently in https://html.spec.whatwg.org/#creating-a-css-module-script . I didn't realize that would result in redundant fetches. (Which you can write WPTs about by using the server; see e.g. web-platform-tests/wpt#30259 for a similar scenario.)

Probably we should keep the exposure check as the method of determining whether it's supported? But just move it to somewhere early in the pipeline... I think "fetch a single module script" would work.

[annevk]

I don't see how exposure would work for import.meta.supportsType("css")? I was thinking we'd just have an algorithm that given a module type and an agent type, returns true or false.

[domenic]

Sure, that would probably help more for such future scenarios. Although I'd suggest the algorithm take an environment settings object and a module type.

[dandclark]

Seems to me like we can check for this at the same spots where we already check (before the fetch) that the asserted type is "json"/"css". I took a crack at this here: #7066