-
Notifications
You must be signed in to change notification settings - Fork 32
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
Semantics of this feature in HTML/the Web #24
Comments
Note, the above talks about how integration with |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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 |
If we want to allow overlapping MIME type sets, as discussed in #16 (
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. |
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 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 import css from './global.css' with { type: 'css' } Browser send body { color: red; } import css from './global.css' Browser send 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 |
Why wouldn't the type be 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? |
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:import
statement or dynamicimport()
, it passes an optional additional parameter to the embedder, of the options bag of module attributes.type:
. If thetype
is present and unrecognized, module fetching and parsing is aborted with an error.type
, and if notype
is provided, then JavaScript is implicitly used. Each knowntype
has a set of MIME types that it permits. If the MIME type is not contained in thetype
'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.type:
). Thetype:
is not used at this point--it simply provided an additional check before the parser was invoked.Any thoughts on this logic?
The text was updated successfully, but these errors were encountered: