Add text imports

[eemeli]

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.

• At least two implementers are interested (and none opposed):
  • Chromium
  • Gecko
  • Deno
  • Node.js
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
  • Add tests for Import Text proposal tc39/test262#4607
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): Stabilize bytes and text imports denoland/deno#29904
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

[annevk]

cc @nicolo-ribaudo @bakkot

[bakkot]

Looks good. I do wonder whether there ought to be a required MIME type, especially given that the other types all have one. If type: "bytes" had a similar requirement (which IMO would be much more annoying), that would allay the concerns in this issue.

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.

[zcorpan]

Would this make available the same content that is already available via fetch()? Is it possible to use CSP (connect-src ?) to restrict these imports?

[bakkot]

Good question. Looks like type: "json" imports are governed by connect-src, so I assume these should be as well. This will require filing a PR against CSP updating the "Get the effective directive for request" algorithm to list requests with destination "text" as having effective directive connect-src. (Not strictly necessary because connect-src is the fallback, but it would be weird to leave it out given that "json" imports are listed explicitly.)

For clarity it might be good to rename the destination to "text-import" or something, incidentally.

Anyway, yes, this ends up letting you get the exact same content as fetch.

[nicolo-ribaudo]

Do we actually want a text destination? We added one for json because it's a specific format, but in most cases a text import will then be parsed by something else. fetch uses an empty destination because, similarly, we don't actually know how its result is going to be used.

[bakkot]

json doesn't seem any more specific than text to me, really. It's just data either way.

[annevk]

It's specific in that we can ask the server for JSON with Accept: application/json (and we do).

Given that the destination is exposed these days through Sec-Fetch-Dest as well it would probably be useful to have a dedicated value here as well. text seems fine to me.

[bakkot]

Oh, nice, I didn't realize that it got exposed there and wasn't just editorial. In that case I agree text is fine, as long as we don't imagine later introducing a new kind of "text" destination where the distinction is important.