Semantics of this feature in HTML/the Web

Note: The semantics of this proposal on the Web would be standardized in WHATWG/HTML, not in this repository. This issue is purely for requirements-gathering/brainstorming.

The README has examples of using the type: module attribute, but the semantics of this are not really defined anywhere. I think there's been some confusion in the discussion in issues as different people make assumptions about different semantics. Here's how I am currently picturing that this would work on the Web/in HTML:

When JavaScript loads a module, either through an import statement or dynamic import(), it passes an optional additional parameter to the embedder, of the options bag of module attributes.
When HTML gets these module attributes, it ignores unrecognized attributes (for reasons discussed in How should unrecognized attributes or types be handled? #21) and just looks at type:. If the type is present and unrecognized, module fetching and parsing is aborted with an error.
Otherwise, the module is fetched, and the MIME type is compared with the type, and if no type is provided, then JavaScript is implicitly used. Each known type has a set of MIME types that it permits. If the MIME type is not contained in the type's set, then module fetching and parsing also errors out. If the module had already been fetched previously and lived in the cache, then the MIME type is cached along with it and used for this comparison.
The module is then parsed and processed according to its MIME type (which may provide more detailed information than simply the type:). The type: is not used at this point--it simply provided an additional check before the parser was invoked.

Any thoughts on this logic?

Note, the above talks about how integration with type: would work, but I'd imagine the same logic would apply with out-of-band data, the type indicated as part of the module specifier, or with a single piece of additional data rather than key/value pairs.

I think that on the web it's important to set the Accept header when fetching the resource. For example:

import u from "https://a.cf/sven.jpeg" as json

The developer is requesting from the server a file of type json. The host does that by sending an the corresponding Accept header.

The module is then parsed and processed according to its MIME type (which may provide more detailed information than simply the type:). The type: is not used at this point--it simply provided an additional check before the parser was invoked.

If we want to allow overlapping MIME type sets, as discussed in #16 (image/foobar+json etc), then in this step it is the type attribute, rather than the MIME type, that is what must be used to determine what kind of module to instantiate, or else we're left with some ambiguity.

([the MIME type] may provide more detailed information than simply the type)

Could you elaborate on this a bit? For modules, I'm not sure what information could be gleaned from the MIME type other than which type of module we should instantiate.

@xtuc

Well, as @xtuc mentioned, if JS BinAst has a different MIME type, it may require different processing, even if it's also a JS module.

Is "script" the only tag that will needs this feature? In particular, does it make sense to loading images or templates (already supported via the template tag) using a script tag?

@jfparadis

@jfparadis Could you say more about what you mean by that? I could imagine other sorts of attributes passed to other subresources (e.g., fetch options or integrity), and these could be passed through other tags (or out-of-band manifests).

I'd like to expect the browser to send different Sec-Fetch-Dest header based on different type.

import css from './global.css' with { type: 'css' }

Browser send Sec-Fetch-Dest: style and Server can return this based on the header

body { color: red; }

import css from './global.css'

Browser send Sec-Fetch-Dest: script and Server can return this based on the header

const css = new CSSStyleSheet()
const hasImport = x.includes('@import')
if (hasImport) css.replace(x)
else css.replaceSync(x)
export default css

Can we agree that the HTML/Web semantics needs to be worked out by Stage 3, but that we have a rough outline for how type would work, enough to get us to Stage 2?

Why wouldn't the type be application/json? As in:

import u from "https://a.cf/sven.json" as application/json

or

import u from "https://a.cf/sven.json" assert { accept: 'application/json' }

Then you could just pass it as the accept verbatim? Are you going to map assert types to all mime types and all future mime types?

Navigation Menu

Repository navigation

Semantics of this feature in HTML/the Web #24

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Semantics of this feature in HTML/the Web #24

Description

Activity

littledan commented on Nov 9, 2019

ljharb commented on Nov 9, 2019

littledan commented on Nov 9, 2019

ljharb commented on Nov 9, 2019

littledan commented on Nov 9, 2019

ljharb commented on Nov 9, 2019

littledan commented on Nov 9, 2019

xtuc commented on Nov 11, 2019

dandclark commented on Nov 14, 2019

littledan commented on Nov 14, 2019

jfparadis commented on Nov 25, 2019

littledan commented on Nov 25, 2019

Jack-Works commented on May 12, 2020

littledan commented on May 20, 2020

justinmchase commented on Oct 12, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions