Inferring module type from MIME type vs type attribute needs clarification

[nayeemrmn]

This is regarding the explained purpose of the type attribute -- not attributes in general.

With the assert syntax it was obvious that the type of module is ultimately inferred from the MIME header or whatever the host decides, and the asserted type wouldn't change behaviour of the program except to error or not.

import foo from "foo.json" assert { type: "json" };

However with the with syntax, it's not so obvious anymore. But from what I understand and based on https://github.com/tc39/proposal-json-modules which is still stage 3, it's still the case that the type attribute generally doesn't alter non-errant behaviour and the module type is still absolutely determined from the mime type.

import foo from "foo.json" with { type: "json" };

Is that correct? Then it would be weird if hosts started using the same attribute key for things which do alter behaviour, instead of just exploring other keys like { type: "image", as: "canvas"}. I think it should still be strongly discouraged.

So then... should the type attribute be renamed to assertType or something to better indicate that? This would require a breaking change / demotion to https://github.com/tc39/proposal-json-modules as well.

Related issue:

• Add type: "any" #116 - Imagine with { type: "any" } vs with { assertType: "any" }.

[nayeemrmn]

Actually looking at WICG/webcomponents#839 and whatwg/html#7233 side-by-side, shouldn't security-mandated attributes just be true to purpose and look like this?

import foo from "./foo.css" with { csp: "style-src" };
// or
import foo from "./foo.css" with { csp: "weak" };
import bar from "./bar.json" with { csp: "weak" };

[nicolo-ribaudo]

What would happen on the web after whatwg/html#7233 is that type will hint to the server what type of module is expected (so it's not just an assertion), and then it will throw if the response doesn't actually match the expected type.

The reason that this proposal has been changed even after reaching stage 3 is that what HTML needs/wants is not just an assertion.

I think it's good to consider more possible import attributes, but at this point that discussion better fits in the HTML repo than here.

[nayeemrmn]

Thanks for the reply. I'm using the word "assertion" imprecisely and perhaps the name assertType is off the table since it's sent to the host on request.

But the distinction I'm talking about is the intended purpose of the type attribute generally being to "specify an expectation" on the MIME -> module type rather than to, say, select a transformation on the module type.

The documentation here, written under the assumption of assert { ... } being the surrounding syntax, now lacks needed clarity on what the type attribute is meant for. In my opinion the same applies to name type. Obviously I'm not proposing more attributes.

[ljharb]

The syntax has changed; its now “with” instead of “assert”.

[nayeemrmn]

The syntax has changed; its now “with” instead of “assert”.

@ljharb Yeah this issue is after that, could you elaborate on your point?

[ljharb]

@nayeemrmn ah sorry, i misread your comment. You're saying that the docs need to improve.

[nayeemrmn]

This issue is too broad to keep open.

But basically my thought was that it would be appropriate for https://github.com/tc39/proposal-import-attributes/blob/cf907580dc890f3d0329a4376368c8f845260fdb/README.md#proposed-semantics-and-interoperability to actively suggest that type be used to validate against the MIME type (or similar) as it does for JSON modules on the web, not to apply transforms. I can easily see hosts doing that and then the spirit of the type attribute would be confusing. This message was lost when the syntax changed from assert to with event though the purpose in spirit of the type key didn't really change.