Among the things new to the web platform in February, one stands out for anyone who has shipped a feature that renders user-supplied markup: a native HTML Sanitizer API, now in Firefox 148 and Chrome 146. It filters HTML before it is inserted into the page, the way a sanitizer library does today, to reduce the risk of cross-site scripting (XSS). The same month brought the customizable select element in Chrome and the shape() function in CSS.
I think the sanitizer is the one with a decision attached. For years the right answer to rendering untrusted HTML has been a well-maintained library, and teams have one in their dependency tree, often several copies of it. A native API changes what the plan should be.
My view is that the plan should be retirement, not addition. Every sanitizer in node_modules is a dependency with its own release cadence, its own supply chain, and its own bugs. A browser-native sanitizer is maintained by the browser, updated with it, and is attack surface a team no longer owns. The path is to put the native API behind the same interface, let it take over where it exists, and set a date to remove the library once the browsers you support all have it.
Where in your stack is untrusted HTML rendered, and does anyone own the plan for that code?
Photo source: https://photos.robertstowe.com/texas