Integrate fragment parser options with trusted types by noamr · Pull Request #12583 · whatwg/html

noamr · 2026-06-16T14:05:44Z

In almost* all of the places where where TrustedTypes' createHTML is called,
we now also check for createParserOptions and call that if it's available, by calling "get trusted types compliant input" instead of "get trusted types compliant string".

The exceptions to this are srcdoc, document.write(), and the insertHTML execCommand. We can resolve separately as to whether these should also be sanitized with createParserOptions.

This now allows us to use the sanitizer in legacy markup insertion methods like the innerHTML setter, and to
disallow running scripts in createContextualFragment.

Since all markup insertion methods can now include a sanitizer, most of the steps from "set and filter HTML" are folded into the "fragment parsing algorithm steps", and it's assumed that there is always a sanitizer (though sometimes with an empty configuration).

Together with w3c/trusted-types#606

At least two implementers are interested (and none opposed):
- Chromium
- ?
Tests are written and can be reviewed and commented upon at:
- Mark createParserOption tests non-tentative web-platform-tests/wpt#61260
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/issues/491743369
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2043150
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=315741
MDN issue is filed: Part of blink release process
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 17, 2026, 1:14 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 · 2026-07-17T12:25:46Z

Two things for the top comment, I don't think you do fold set and filter html anymore?

Also this also doesn't touch execCommand with the insertHTML command. (This is probably the right move because that isnt specced correctly to start with. But worth calling out probably).

lukewarlow · 2026-07-17T12:46:22Z

+   while <span data-x="allow declarative shadow roots">declarative shadow roots</span> are ignored.
+   <span data-x="XML documents">XML documents</span> are parsed using the XML parser.</dd>
+
+   <dt><dfn data-x="fragment-parser-mode-unsafe">Unsafe</dfn></dt>


Is it worth clarifying the XML behaviour here and below?

sure, added something

noamr · 2026-07-17T13:11:39Z

Two things for the top comment, I don't think you do fold set and filter html anymore?

Also this also doesn't touch execCommand with the insertHTML command. (This is probably the right move because that isnt specced correctly to start with. But worth calling out probably).

Thanks, OP updated.

lukewarlow · 2026-07-17T13:17:44Z

Did we decide it was okay to not enforce the sanitizing if the document was XML?

noamr · 2026-07-17T13:20:42Z

Did we decide it was okay to not enforce the sanitizing if the document was XML?

That's what I understood but @mozfreddyb, @evilpie or @otherdaniel would know more. Sanitization is not specified for the XML parser.
Note that this is the status quo that is not changed here - what this does is allows you to sanitize when setting HTML with one of the old methods (and soon with streaming).

otherdaniel · 2026-07-17T14:56:42Z

Did we decide it was okay to not enforce the sanitizing if the document was XML?

That's what I understood but @mozfreddyb, @evilpie or @otherdaniel would know more. Sanitization is not specified for the XML parser. Note that this is the status quo that is not changed here - what this does is allows you to sanitize when setting HTML with one of the old methods (and soon with streaming).

What I remember is that we specified Sanitizer API only for methods that would inherently only support HTML syntax. setHTML, setHTMLUnsafe, parseHTML, and parseHTMLUnsafe were all new methods, that simply don't support XML syntax. It's right there in the names. We didn't say what to do for XML syntax because we didn't have to.

This is probably best articulated in the hopelessly outdated explainer

Nearly all interesting bits are specified in terms of DOM & DOM operations, so I'd expect this to be easy to adapt to XML. But IMHO, application to XML-parser parse trees requires a second look, since it invalidates one of the assumptions we had when specifying any of this.

A silly example, but the only one I can think of: CDataSection in https://wicg.github.io/sanitizer-api/#sanitize-core step 1.1. That shouldn't be difficult to fix; but at least for now Sanitizer would assert-fail on (some) XML parse trees. In our implementation, there's a runtime assert there.

lukewarlow · 2026-07-17T16:36:53Z

I guess my main concern is people defining a trusted types policy with this new function thinking it protects them and then it doesn't because they're in XHTML or something?

Assuming I'm reading this right you'd end up with a default policy explicitly setup to remove unsafe and then it actually no-ops when it's called by a legacy sync in XML.

noamr · 2026-07-17T16:43:21Z

I guess my main concern is people defining a trusted types policy with this new function thinking it protects them and then it doesn't because they're in XHTML or something?
Assuming I'm reading this right you'd end up with a default policy explicitly setup to remove unsafe and then it actually no-ops when it's called by a legacy sync in XML.

You mean sink?

Yea it's limited in that way. But createHTML is still there... until we have some solution for this people should probably still use both in their policy or protect XML in other means.

noamr · 2026-07-17T17:35:21Z

I guess my main concern is people defining a trusted types policy with this new function thinking it protects them and then it doesn't because they're in XHTML or something?
Assuming I'm reading this right you'd end up with a default policy explicitly setup to remove unsafe and then it actually no-ops when it's called by a legacy sync in XML.

You mean sink?

Yea it's limited in that way. But createHTML is still there... until we have some solution for this people should probably still use both in their policy or protect XML in other means.

I think that the specific guidance to developers to be to check the type of document when they create the default policy, use createHTML with the appropriate userland sanitizer if either this is an XML document or TrustedParserOptions is not supported, and createParserOptions otherwise

noamr force-pushed the noamr/cpo branch from 936b727 to 111b9ad Compare July 2, 2026 09:50

noamr force-pushed the noamr/cpo branch from 111b9ad to 2af1592 Compare July 13, 2026 18:38

noamr changed the title ~~Integrate createParserOptions (draft)~~ Integrate createParserOptions Jul 13, 2026

noamr changed the title ~~Integrate createParserOptions~~ Integrate fragment parser options with trusted types Jul 13, 2026

noamr closed this Jul 13, 2026

noamr reopened this Jul 13, 2026

noamr force-pushed the noamr/cpo branch from 2af1592 to 12879d6 Compare July 13, 2026 19:36

noamr mentioned this pull request Jul 13, 2026

Mark createParserOption tests non-tentative web-platform-tests/wpt#61260

Open

noamr marked this pull request as ready for review July 13, 2026 19:43

noamr requested review from annevk, lukewarlow and zcorpan July 13, 2026 19:46

noamr added the agenda+ To be discussed at a triage meeting label Jul 15, 2026

lukewarlow reviewed Jul 17, 2026

View reviewed changes

noamr added 4 commits July 17, 2026 14:13

createParserOptions

b8c0281

TrustedParseOptions in IDL

90a3982

Still wrap things in set and filter HTML

a9a9535

Add clarification about XMLL vs HTML

91e333c

noamr force-pushed the noamr/cpo branch from ed1e30f to 91e333c Compare July 17, 2026 13:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Integrate fragment parser options with trusted types#12583

Integrate fragment parser options with trusted types#12583
noamr wants to merge 4 commits into
mainfrom
noamr/cpo

noamr commented Jun 16, 2026 •

edited by pr-preview Bot

Loading

Uh oh!

lukewarlow commented Jul 17, 2026

Uh oh!

lukewarlow Jul 17, 2026

Uh oh!

noamr Jul 17, 2026

Uh oh!

noamr commented Jul 17, 2026

Uh oh!

lukewarlow commented Jul 17, 2026

Uh oh!

noamr commented Jul 17, 2026 •

edited

Loading

Uh oh!

otherdaniel commented Jul 17, 2026

Uh oh!

lukewarlow commented Jul 17, 2026

Uh oh!

noamr commented Jul 17, 2026

Uh oh!

noamr commented Jul 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

noamr commented Jun 16, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

💥 Error: Wattsi server error 💥

Uh oh!

lukewarlow commented Jul 17, 2026

Uh oh!

lukewarlow Jul 17, 2026

Choose a reason for hiding this comment

Uh oh!

noamr Jul 17, 2026

Choose a reason for hiding this comment

Uh oh!

noamr commented Jul 17, 2026

Uh oh!

lukewarlow commented Jul 17, 2026

Uh oh!

noamr commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

otherdaniel commented Jul 17, 2026

Uh oh!

lukewarlow commented Jul 17, 2026

Uh oh!

noamr commented Jul 17, 2026

Uh oh!

noamr commented Jul 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

noamr commented Jun 16, 2026 •

edited by pr-preview Bot

Loading

noamr commented Jul 17, 2026 •

edited

Loading