Earlier quoted context omitted.
`setHTML` is meant as a replacement for `innerHTML`. In the use case you describe, you would have never wanted `innerHTML` anyway. You'd want `innerText` or `textContent`.
But that's what setHTML isn't at all a replacement for innerHTML. You still need innerHTML when you want to inject HTML tags in the page, and you could already use innerText when you didn't want to. Having something in between is seriously useless.
Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
171–172 of 172 posts
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#172Earlier quoted context omitted.
It is not a hard requirement that untrusted input is "treated like text". It's also not a hard requirement that I defend the position that there's a hard requirement for untrusted input to be treated like text. That isn't my position, and it's not what I wrote. Given that it is not a hard requirement that untrusted input be treated like text, it wouldn't make sense for anyone to claim that it is—and therefore it does…
I thought you were done talking to me? Briefly though, if you have an untrusted string then you need to either treat it like text or sanitize it. I don't see any other options. So if people shouldn't use this sanitizer or write their own, then the only option left is treating the string as text. But you're vehemently arguing that's not what you said. What's the other way to use an untrusted string? Other than "don't"…