Repository navigation
Add text imports - #11933
Add text imports#11933
Conversation
Adds support for the `{ type: 'text' }` import attribute,
which enables importing text content as a JavaScript string.
annevk
added
addition/proposal
|
Looks good. I do wonder whether there ought to be a required MIME type, especially given that the other types all have one. If Alternatively there could be a requirement not to have certain MIME types, e.g. to disallow importing JavaScript as text. I think I am personally inclined not to impose such requirements, but I could see the argument either way. |
|
Would this make available the same content that is already available via |
|
Good question. Looks like For clarity it might be good to rename the destination to Anyway, yes, this ends up letting you get the exact same content as |
|
Do we actually want a |
|
|
|
It's specific in that we can ask the server for JSON with Given that the destination is exposed these days through |
|
Oh, nice, I didn't realize that it got exposed there and wasn't just editorial. In that case I agree |
|
The TC39 / ECMA-262 part of this proposal has now advanced to Stage 3. |
noamr
left a comment
noamr
left a comment
There was a problem hiding this comment.
I think this needs to be rebased, and properly support modulepreload like CSS/JSON.
|
Do the tests cover module preload? The spec text seemed good AFAICT! |
noamr
left a comment
noamr
left a comment
There was a problem hiding this comment.
Unofficial LGTM % tests for modulepreload
@noamr They do now (I just updated the WPT PR). |
annevk
left a comment
annevk
left a comment
There was a problem hiding this comment.
This looks good to me. It would be great if @nicolo-ribaudo could also do a quick skim.
|
MDN and browser bugs should be completed for this as well before landing. |
Done. |
|
@eemeli can you detail how this PR addresses the concerns you've linked to in tc39/proposal-import-text#8? The PR description says they should be addressed in this PR. Maybe they are? It would be good to flesh it out. |
|
@noamr The concerns raised in tc39/proposal-import-text#8 lead to tc39/proposal-import-text#10, which added a non-normative qualifier that the String representing the imported module "should represent textual data". This recalls the pre-existing spec description of Strings as "generally used to represent textual data". As you note, this proposal has imported text modules always being parsed as UTF-8, as required by the Encoding standard. And so if the imported bytes do not in fact represent text, we end up with an unusable string full of lossy � replacements, and not e.g. a base64 representation of it, or some other reversible binary-as-text mapping. Once a text module has been imported, we can (and should) presume that it'll be used for something; either presented directly to the user, or parsed for some further meaning. In either case, a UTF-8 parsing of binary data will be readily apparent as not fulfilling whatever need is put to it, and the error can be addressed by the developer. However, this assertion of "readily apparent" is rather dependent on having some idea of the expected shape of the textual data, which we don't know for the general case: Maybe it's prose that's been incorrectly encoded and decoded resulting in a smattering of replacement characters; maybe it's an XML document; maybe it's base122 encoded data. And so if we do want to identify the errors caused by parsing binary data as text a bit earlier, and in a way that would make those errors non-recoverable (you can't try-catch an import statement), I agree that filtering on the MIME type is perhaps the only available recourse. That does leave us with the problem of identifying "textual" MIME types, for which I'm not aware of a pre-existing registry or heuristic -- or is there one I've missed? Relying on the IANA registry's "Encoding Considerations" section is not really appropriate: as noted in its application form,
Relying on such a registry would also introduce unnecessary points of divergence between implementations. For example, To summarize, I think the concerns that have been raised are addressed as well as they can be by this proposal, and that introducing additional filtering, sniffing, or heuristics is not warranted, given the real-world limitations we need to contend with, and the negative consequences of doing so. |
|
Thanks for the detailed response, @eemeli. This is resolved as far as I'm concerned. |
This is to support the spec changes in: - https://github.com/tc39/proposal-import-text - whatwg/html#11933 - whatwg/fetch#1898 - w3c/webappsec-csp#794
Automatic update from web-platform-tests Add tests for text modules This is to support the spec changes in: - https://github.com/tc39/proposal-import-text - whatwg/html#11933 - whatwg/fetch#1898 - w3c/webappsec-csp#794 -- wpt-commits: 5419f98d72f4b1ae49980581a6a66710d6a3dee7 wpt-pr: 56812
Automatic update from web-platform-tests Add tests for text modules This is to support the spec changes in: - https://github.com/tc39/proposal-import-text - whatwg/html#11933 - whatwg/fetch#1898 - w3c/webappsec-csp#794 -- wpt-commits: 5419f98d72f4b1ae49980581a6a66710d6a3dee7 wpt-pr: 56812
MDN documents type:"text" substantively in the import-attributes reference (dedicated Text Modules subsection with example, loading behaviour, specs + compat; verified 2026-10-18), so this is an honest stub rather than a duplicate reference. Quick reference carries the verbatim TC39 README syntax example, the merged host-integration trail (whatwg/html#11933, whatwg/fetch#1898, w3c/webappsec-csp#794), and webstatus.dev text-modules data (Chrome 155 / Edge 155 / Firefox 153 / Safari not yet; Baseline limited) labelled as web-features data since no dedicated BCD key resolved yet. Showcase feature route + all three concept routes HEAD-checked 200. Conformance green, responsive matrix ok on both classes (screenshots read). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ho5RCZeaUQC54N8sSJCvkN
…loader; cached import() settles in microtasks; modulepreload into the module map Lane module1 (brief tmp/orchestration/briefs/module1-final.md), items 1-4. 1. Text module scripts (HTML "create a text module script", whatwg/html#11933, merged 2026-04-01; TC39 proposal-import-text CreateTextModule): ModuleType.text ("text:" map key), the "text" import attribute, "fetch destination from module type" (new ModuleType.fetchDestination; Fetch's "text" destination joins Destination, isSubresourceRequest, the Accept header text/plain,*/*;q=0.5 and Request.destination), and fetch-single step 13.7: the body UTF-8 decoded whatever its Content-Type, as a default-export synthetic module (engine.createDefaultExportSyntheticModule with a string). Golden rule 2: newer spec shipped by Chrome and Firefox (text-module/module.html, charset-bom.any.html PASS; Safari ERROR) at wpt.fyi stable df642c4142. Worker import() checks "module type allowed" instead of special-casing css. 2. Worker import() through module_script.AsyncModuleLoader, the Window's callback-list loader: its owner generalised from the Document to the settings object's platform object (owner/owner_generation; WebKit's ScriptModuleLoader serves Document and WorkerGlobalScope alike). The WorkerHost makes it on first import(), each import is a LoaderImport client (done/gone finish the engine request), and the realm's end destroys it after the loop's tasks are dropped and before disposeModules. The request starts at import() (a revoked blob URL still loads), joins an in-flight fetch, and its referrer and fetch options are the referencing script's (HostLoadImportedModule steps 5-6, 14). A service worker's import() keeps its old queued path (lane sw1). The synchronous path (a module worker's own graph, ShadowRealm import(), engine-less contexts) no longer keeps a failed fetch: the fetch_failed sentinel is gone (fetch-single step 13.1, whatwg/html#10327), and with it a container-level var (global-state baseline 289 -> 288). 3. An import() whose whole graph is in the module map completes from a realm microtask, not a task (Client.settle_cached_in_microtask, set by the Window's and the workers' import()). ECMA-262 ContinueDynamicImport links and evaluates in a reaction to the settled loadPromise, so one microtask is the spec's ordering; no protocol change. Golden rule 2, first case (integrator, 2026-10-18): wpt PR #35949 with whatwg/html#8264; Safari ships it in both globals, Firefox in workers. 4. <link rel=modulepreload> fetches through the document's module loader (script_execution.fetchModulePreload -> AsyncModuleLoader.startModulePreload): "fetch a modulepreload module script graph" puts the module into the module map, so a later import() takes it, or joins its fetch, under the link's referrer policy (modulepreload-referrerpolicy 7/7 in all three browsers). Step 3 accepts every module preload destination (json, style, text, script-like). The load names its fetch by id (ModulePreload), so a load that ends first leaves the fetch to the map. Resource Timing initiatorType stays "link". The optional descendants step is not done. Tests (red at 3b12eef: tmp/debug/red1-main-3b12eef2f4.log, green here): tests/html/module1_text_module_test.zig, module1_worker_imports_test.zig (retry after failure, joined fetches, joined failure with a sibling refetch, microtask settling - Window, module, classic and shared workers; termination with imports in flight; two Browsers on two threads loading one diamond graph in workers, per-Browser DebugAllocator), module1_modulepreload_test.zig, over a loopback server behind the Browser's proxy (module1_http_server.zig). Unit tests pin moduleTypeFromAttribute and fetchDestination.
This is the HTML counterpart for the newly-introduced TC39 Import Text Stage 2 proposal; this has been previously discussed here in #9444, and is closely related (but not blocking on) PR #11657, which correspondingly adds byte imports.
The
type: 'text'import attribute is introduced here without any MIME type requirement, and without any validity or well-formedness checks on the returned string value. @sffc has raised some concerns about additional validation steps being desirable for text content, which would be appropriate for consideration in this spec, rather than the JS spec.The implementer support noted below is based on feedback from delegates at the 2025 November TC39 meeting.
/acknowledgements.html ( diff )
/infrastructure.html ( diff )
/links.html ( diff )
/references.html ( diff )
/webappapis.html ( diff )