Rebased now that #805 is merged.

From my pov this is ready for a review, see discussion in #789.

Friendly ping, this seems to be the most efficient way we can prevent attribute node bypasses in Trusted Types by rejecting the value without potentially calling the default policy on all attr mutations.

I think this makes sense, but we should add a note explaining this setup somewhere close to where it's relevant.

This should have implementor interest now given Mozilla's positive standards position on trusted types as a whole.

I wonder if we want an arbitrary extension point for this or just call into Trusted Types directly. With an arbitrary extension point we have the risk of running into ordering issues so we tend to avoid those these days, even though the DOM has some precedent for it (mainly historical).

I wonder if we want an arbitrary extension point for this or just call into Trusted Types directly.

I don't have a strong preference here. As long as it is possible to guard attribute mutations done by the DOM APIs, the actual algorithms can be defined in either spec. This PR was the only necessary integration point of TT with DOM.

What might be problematic is not technical, i.e. can DOM call out to specs that are currently at FPWD? Waiting until CR is probably not very useful to the authors here, especially with shipped implementations.

That's not really an issue, especially for integration points. And in fact, we tend to prefer referencing the latest editor's draft.

Definite +1 for a direct call out.

#1247 and w3c/trusted-types#418 supercede this one. Unfortunately handling the attr mutation in DOM happens now after setting the new value, so I had to add an explicit new step to the algorithms.