1. Safety vs. “sanitisation” is still a moving target
“I’m also rather sceptical of things that ‘sanitise’ HTML, both because there’s a long history of them having holes, and because it’s not immediately clear what that means, and what exactly is considered ‘safe’.” – entuno
“If you still want to allow some markup, you can configure the sanitizer… but you still need to be careful.” – itishappy
2. Naming matters – the API should make danger obvious
“The ‘unsafe’ suffix conveys information to the reader, whereas
innerHTMLdoes not.” – orf
“The only way to make the unsafe path feel unsafe is to name it that way.” – kevincloudsec
3. Legacy, compatibility and browser support are real hurdles
“At this point that API has been around for decades and is probably impossible to deprecate without breaking fairly large amounts of the web.” – entuno
“It might be a while before browser support is widely distributed enough to rely on it being present.” – simonw
4. When and why you’d actually use the new API
“Use
setHTMLwhen you need to render HTML that is potentially unsafe (e.g. forum posts or IM messages).” – chrisldgk
“If you want to allow<strong>and<em>in a forum post but not<script>, this is the right tool.” – benmmurphy
These four themes capture the core of the discussion: the ongoing debate over XSS safety, the importance of clear naming, the practical limits of adoption, and the specific scenarios where the new API is useful.