The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality.
If you want to adopt this in your project, you can add a linter that explicitly bans innerHTML (and then go fix the issues it finds). Obviously Mozilla cannot magically fix the code of every website on the web but the tools exist for _your_ website.
I kinda like the way JS evolved into a modern language, where essentially ~everyone uses a linter that e.g. prevents the use of `var`. Sure, it's technically still in the language, but it's almost never used anymore.
(Assuming transpilers have stopped outputting it, which I'm not confident about.)
extraduder_ire|5 days ago
Good idea to ship that one first, when it's easier to implement and is going to be the unsafe fallback going forward.
onion2k|5 days ago
Oddly though, the Sanitizer API that it's built on doesn't appear to be in Safari. https://developer.mozilla.org/en-US/docs/Web/API/Sanitizer
croes|5 days ago
orf|5 days ago
tbrownaw|5 days ago
philipwhiuk|5 days ago
reddalo|5 days ago
post-it|5 days ago
The mythical refactor where all deprecated code is replaced with modern code. I'm not sure it has ever happened.
I don't have an alternative of course, adding new methods while keeping the old ones is the only way to edit an append-only standard like the web.
thenewnewguy|5 days ago
Vinnl|5 days ago
(Assuming transpilers have stopped outputting it, which I'm not confident about.)
bulbar|5 days ago
littlestymaar|5 days ago
Having an alternative to innerHTML means you can ban it from new code through linting.
noduerme|5 days ago