Semantics of this feature in HTML/the Web · Issue #24 · tc39/proposal-import-attributes (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

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?