> This is pretty similar to the Sanitizer that I wanted to build into the browser: […] But that is NOT the Sanitizer we ended up with.¶ And the reason is essent

> This is pretty similar to the Sanitizer that I wanted to build into the browser: […] But that is NOT the Sanitizer we ended up with.¶ And the reason is essentially Mutated XSS (mXSS). To quickly recap, the idea behind mXSS is[…] No, the reason is that the problem is underspecified and unsatisfiable. The whole notion of HTML "sanitization" is the ultimate "just do what I mean". It's the customer who cannot articulate what they need. It's «Hey, how about if there were some sort of `import "nobugs"`?» "HTML sanitization" is never going to be solved because it's not solvable. There's no getting around knowing whether or any arbitrary string is legitimate markup from a trusted source or some untrusted input that needs to be treated like text. This is a hard requirement. (And if you already have this information, then the necessary tools have been available for years—decades, even: `innerHTML` and `textContent`—or if you don't like the latter, then it's trivial to write your own `escapeText` subroutine that's correct, well-formed, and sound.) No new DOMPurify alternative or native API baked into the browser is going to change this, ever.