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.