Re: In-browser sanitization vs. a “Safe Node” in the DOM

Do I understand correctly that the motivation behind this proposal is to
enable people to assign to someElement.innerHTML?

If so, why is it a goal to enable a well-known anti-pattern? If not, ignore
the rest of this message. :)

It reminds me a bit of efforts to make 'safe' string
concatenation/interpolation APIs to stop SQL injection, in a world where
parameterized queries already exist (and often execute faster). Here, we
already have document.createElement, document.createTextNode,
<element>.appendChild, and so on.

In general, enabling well-known anti-patterns seems like a bad idea,
especially when they seem to require magic to implement. For example, what
is the actual mechanism/algorith/heuristic thsi API would use to enforce
the Safe CSS set of policies?

* Safe CSS
>  + Prevent anti-XSRF nonce theft via CSS
>  + Prevent UI overlay
>  + Prevent any identified abuse of existing styles on the page
>  + Prevent styles defined within the Safe Node from affecting the
> surrounding page


Since the usual (reasonable) objection to document.createElement,
document.createTextNode, <element>.appendChild, is that it results in
verbose, blargy code, I'd rather see an API that makes use of techniques
like this
https://developer.mozilla.org/en-US/Add-ons/Code_snippets/HTML_to_DOM —
filtering parsers. Basically, Cure53's DOMPurify, only standardized and
built into the browser and implemented in native code. That way people
could do

    element.innerHTML = purify(untrustworthyString, options...)

That seems convenient enough for callers?