Sounds reasonable enough to me. 99.99% of the times you’re in an actual script, if you mean to execute code, you’d just execute it yourself, rather than making a script tag full of code and sticking that tag into a random DOM element. That’s why the default wouldn’t honor the script tag and there’d be an “unsafe” method explicitly named as such to hint you that you’re doing something weird.
But it breaks an abstraction. Sometimes you just want to take working HTML and insert it into a document. It will be painful if suddenly this does not work, and you have to dig into the documentation to see why.
It is also painful when your app gets hacked, accounts get taken over and abused, user data is compromised, and so on. For serious sites it's worth the pain to turn on security enforcement features.
Ok, but be sure to make it optional. Putting 10 locks on your door is great for security, but it's not for everyone.
And instead of this security feature some might want to take a more fundamental look at security which might lead them to a completely different design. Again, make it optional.
If a developer so green that they don’t know what script injection risk is, and doesn’t know about innerHTML vs this method, stumbles into that scenario, I want them to encounter friction and have to dig into the documentation to find out why their script tag wasn’t run. Then they can start to learn how to do their job correctly. Having everything “just work” unsafely by default is not a viable best practice on the Web in 2025. Things have been slowly changing in this direction for at least a decade.
In fact, it’s better for the industry even if a few such individuals are so pained by having to learn about and handle security that they just quit web development entirely. Just like aspiring pilots who can’t stand checklists and safety rules should pursue a different career.
