Skip to content

Add HTMLScriptElement IDL changes for Trusted Types#12195

Open
lukewarlow wants to merge 2 commits into
whatwg:mainfrom
lukewarlow:upstream-script-idl-trusted-types
Open

Add HTMLScriptElement IDL changes for Trusted Types#12195
lukewarlow wants to merge 2 commits into
whatwg:mainfrom
lukewarlow:upstream-script-idl-trusted-types

Conversation

@lukewarlow

@lukewarlow lukewarlow commented Feb 24, 2026

Copy link
Copy Markdown
Member

Add HTMLScriptElement IDL changes for Trusted Types

This upstreams the changes to HTMLScriptElement's IDL that was previously patched by the trusted types specification.

HTMLScriptElement now shadows innerText and textContent, so these can take a TrustedScript object.

Its src and text properties are also updated to take TrustedScriptURL and TrustedScript respectively.

Depends on w3c/trusted-types#607

This has no behaviour changes and is just moving spec text from Trusted Types to the HTML spec.

  • At least two implementers are interested (and none opposed):
    • ...
  • Tests are written and can be reviewed and commented upon at:
  • Implementation bugs are filed:
    • Chromium: …
    • Gecko: …
    • WebKit: …
    • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
    • 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.

(See WHATWG Working Mode: Changes for more details.)


💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Jul 8, 2026, 2:20 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

Error output:

      <!DOCTYPE html>
      <html>
      <head>
          <meta name="viewport" content="width=device-width, initial-scale=1">
          <meta name="robots" content="noindex">
          <style>body,html{height:100%;margin:0}body{display:flex;align-items:center;justify-content:center;flex-direction:column;-webkit-font-smoothing:antialiased;text-rendering:optimizeLegibility}p{text-align:center;font-family:-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Oxygen,Ubuntu,Cantarell,Fira Sans,Droid Sans,Helvetica Neue,sans-serif;color:#000;font-size:14px;margin-top:-50px}p.code{font-size:24px;font-weight:500;border-bottom:1px solid #e0e1e2;padding:0 20px 15px}p.text{margin:0}a,a:visited{color:#aaa}</style>
      </head>
      <body>
      <p class="code">
        Error code: 503      </p>
      <p class="text">
        Well, This is unexpected. An Error has occurred, and we are working to fix the problem! We will be up and running shortly. Try refreshing the page or try again in a few minutes.
      </p>
        <div style="display:none;">
          <h1>
    upstream_reset_before_response_started{connection_termination} (503 UC)      </h1>
          <p data-translate="connection_timed_out">App Platform failed to forward this request to the application.</p>
      </div>
      </body>
      </html>
    

This seems to be an issue with the Wattsi Server service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can report the issue to the maintainers of Wattsi Server directly. Please be courteous. Thank you!

If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Wattsi Server, you can file an issue with PR Preview.

@lukewarlow

lukewarlow commented Feb 24, 2026

Copy link
Copy Markdown
Member Author

Upstreaming these changes without the rest is useful for typescript etc to derive types from IDL, the other parts around script elements are less well defined so probably shouldn't be upstreamed to HTML yet.

Though potentially as a follow-up we can export an algorithm from the Trusted Types spec, that we call from HTML so we're not monkey patching prepare the script algorithm within Trusted Types forevermore.

@annevk annevk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this. I have some concerns:

  1. Did we reach agreement on shadowing all these properties?
  2. I think we should add some kind of issue marker about the unresolved issues with the script element if we make it appear more complete.

@lukewarlow

lukewarlow commented Feb 25, 2026

Copy link
Copy Markdown
Member Author

Did we reach agreement on shadowing all these properties?

It's what is now implemented in all 3 major engines. So I guess yes? I'm not sure if this is something that needs further discussion but I guess the cats already out the bag.

Fwiw it specifically came from a WebKit review on the original design being quite complicated and potentially perf sensitive.

I think we should add some kind of issue marker about the unresolved issues with the script element if we make it appear more complete.

So with these change I did deliberately call into the trusted types spec to avoid anything "unfinished" within the HTML spec itself, but I'm happy to add an issue marker, I'll have a think on exactly what to put in it (happy to take usggestions if you have any)

@lukewarlow

Copy link
Copy Markdown
Member Author

@annevk out of interest if I rebase this and move an issue block somewhere to the script section to replicate what is mentioned in the trusted types spec above incompleteness, would you be open to accepting it? Or do you want an alternative approach? It would be good to fix the webref issue. If it's not desirable to upstream I can look into alternative fixes for that.

@annevk

annevk commented Jun 7, 2026

Copy link
Copy Markdown
Member

I think that would be good enough, yeah.

This upstreams the changes to HTMLScriptElement's IDL that was previously patched by the trusted types specification.

HTMLScriptElement now shadows innerText and textContent, so these can take a TrustedScript object.

Its src and text properties are also updated to take TrustedScriptURL and TrustedScript respectively.
@lukewarlow
lukewarlow force-pushed the upstream-script-idl-trusted-types branch from c157d30 to 46efeca Compare July 8, 2026 14:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants