Element.innerHTML - add info trusted types

[hamishwillee]

This updates the following properties to explain how they are used with TrustedTypes:

• Element.innerHTML
• Element.insertAdjacentHTML()

This is in progress:

• Add boilerplate
• Add TT information, including the new exception and tinyfill
• Restructured - this isn't to current templates. Need to move the guid-ish stuff either down as examples or up into description

This does not mention the sanitizer methods as alternatives since the setHTML() is not implemented anywhere, and the sanitizer in setHTMLUnsafe() is not yet implemented. We're in separate discussion on those and when they are in a release we can revisit.

Part of #37518 (tracking issue)

[github-actions]

Preview URLs

• /en-US/docs/Web/API/Element/innerHTML
• /en-US/docs/Web/API/Element/insertAdjacentHTML

External URLs (3)

URL: /en-US/docs/Web/API/Element/innerHTML
Title: Element: innerHTML property

• https://github.com/cure53/DOMPurify (1 time) (Note! This may be a new URL 👀)
• https://research.securitum.com/dompurify-bypass-using-mxss/ (1 time) (Note! This may be a new URL 👀)

---

URL: /en-US/docs/Web/API/Element/insertAdjacentHTML
Title: Element: insertAdjacentHTML() method

• https://hacks.mozilla.org/2011/11/insertadjacenthtml-enables-faster-html-snippet-injection/ (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2025-08-01 03:34:43)

[hamishwillee]

FYI @lukewarlow @wbamberg - this is the trusted types update for Element.innerHTML. Luke, I've taken on board your comments about sanitizer not yet being implemented. I still mention the setHTMLUnsafe() because it allows set with shadow roots, but not as alternatives with sanitization. It should however be possible to graft that information on here quite easily.

All the examples use trustedHTML. This also shows the first live example use of the tinyfill in the docs. This is duplication with the main docs, but it feels very practical to me given the current state of trustedtypes.

[hamishwillee]

Decided to hide the tinyfill in this case. Do you think it should be here. Or perhaps a note "if trusted types not supported you should add a tinyfill".

[wbamberg]

Just comments on innerHTML for now.

[wbamberg]

Is this supposed to be assigning to textContent?

[hamishwillee]

Doh. Actually though, you'd be safer to use textContent for this - and less hassle.. I'm going to delete the section as pointless

[wbamberg]

Is this example worth keeping? Is this a pattern we want to encourage, versus explicitly creating the DOM elements to put in the log?

and I also wonder, is it a good idea to recommend people to define a no-op TT policy? To what extent does that open up a hole in the whole thing?

[hamishwillee]

I've decided to delete for the reasons given - it doesn't teach anything new, except possibly wrong things.

and I also wonder, is it a good idea to recommend people to define a no-op TT policy? To what extent does that open up a hole in the whole thing?

Right now you should mostly be able to avoid recommending this for HTML but not for script trusted types. In future there are likely to be cases where your policy may need to be no-op - such as when using the unsafe HTML parsing methods. Right now and in this doc you make a good point. We shouldn't.