←back to thread

Element: setHTML() method

(developer.mozilla.org)
170 points todsacerdoti | 1 comments | 22 Oct 25 09:03 UTC | HN request time: 0.404s | source
Show context
ishouldbework ◴[22 Oct 25 21:16 UTC] No.45675241[source]▶
> It then removes any HTML entities that aren't allowed by the sanitizer configuration, and further removes any XSS-unsafe elements or attributes — whether or not they are allowed by the sanitizer configuration.

Emphasis mine. I do not understand this design choice. If I explicitly allow `script` tag, why should it be stripped?

If the method was called setXSSSafeSubsetOfHTML sure I guess, but feels weird for setHTML to have impossible-to-override filter.

replies(8): >>45675325 #>>45675333 #>>45675336 #>>45675342 #>>45675791 #>>45677986 #>>45678424 #>>45678786 #
strbean ◴[22 Oct 25 21:23 UTC] No.45675336[source]▶
This is primarily an ergonomic addition, so it kinda makes sense to me to not make the dangerous footguns more ergonomic in the process. You can still assign `innerHTML` etc. to do the dangerous thing.
replies(2): >>45675456 #>>45675472 #
meowface ◴[22 Oct 25 21:37 UTC] No.45675472[source]▶
I agree, though I also agree with the parent that the method name is a little bit confusing. "safeSetHTML" or "setUntrustedHTML" or something would be clearer.
replies(4): >>45676054 #>>45677128 #>>45677840 #>>45677920 #
jfengel ◴[23 Oct 25 01:17 UTC] No.45677128[source]▶
I like React's dangerouslySetInnerHTML. The name so clearly conveys "you can do this but you really, really, really shouldn't".
replies(1): >>45677701 #
1. domenicd ◴[23 Oct 25 02:54 UTC] No.45677701[source]▶
Indeed, the web platform now has setHTML() and setHTMLUnsafe() to replace the innerHTML setter.

There's also getHTML() (which has extra capabilities over the innerHTML getter).