Similarly to the other example, I wonder about whether we should give people guidance like "we know the input is safe so this policy passes it through without modification".

I suppose part of the issue here is that you want to make it a live sample, but you can't do that and use DOMPurify, so it's hard to make it a "real" example.

One option would be, keep the same code but change the guidance from "we don't need a policy that does anything here" to "in order for this example to work without a third-party dependency, we've implemented a no-op policy here, but you shouldn't do this in real life".

Another option would be to stop making this a live sample, and use DOMPurify, but that would be sad because we want to show the effect of position.

Yet a third option would be to implement our own basic sanitizer, but that might be tricky to get right.

I'd love to know what @aaronshim thinks our guidance here ought to be. Is it good practice to have a no-op policy for content that we "know" is safe?

I've done a modification of "in order for this example to work without a third-party dependency, we've implemented a no-op policy here, but you shouldn't do this in real life".
Its the safest option and the one that most closely matches what we want users to do.
I definitely do not want to remove the live example - it is very helpful for visualising the insert behaviour :-)

I'd love to know what @aaronshim thinks our guidance here ought to be. Is it good practice to have a no-op policy for content that we "know" is safe?

Me too.

I tend to think that the advice should generally be no - if you want to use these unsafe APIs then you're better always sanitizing. In most cases you'd instead replace using TT and use setHTML() (once supported).
Of course the API itself doesn't care, and if the website has a policy that allows noops then developers will be allowed to use said noop policy.

The more interesting noop question is what you do with setHTMLUnsafe() (once supported) - the case where you know you have unsafe strings, but you perhaps need to allow them anyway. If that is a valid case, my contention is that you'd have a noop trusted type to avoid double sanitization.

That's a problem for #40420 (comment)

I'm happy with your choice here and let's merge it. We can always follow up if Aaron recommends something else.