There has been longstanding demand for something like this. Developer interest in DOM Parts has been fairly muted in comparison.

I hope you can make the web components meeting. They are planning to discuss DOM Parts and perhaps NodeGroup/Persistent Fragment, which intersect with your work on Declarative partial updates, if only tangentially

By contrast, CSS bundlers aren't interoperable github.com/romainmenke/...

Personally I'd love to take a minimal standards-aligned slim-build approach where a tool would take my CSS files and put them into one single file using @sheet for each. It would remove the performance impact of @import. Useful for code organisation olliewilliams.xyz/blog/css-imp...

DHH has written about a simple no-build approach but that's always going to be bad for performance. world.hey.com/dhh/once-1-i...

i would mostly like to appearance: base, @layer support for and resolution of github.com/whatwg/html/...

Thanks Luke 💡. Theoretically I get it, although practically I've set my policy to createHTML: (input) => input as I'm not that sure what else I'd do here. It's a lot of extra code. I feel like the naming of the method is already good at getting developers to use some amount of caution.

@bkardell.com I can create a trustedTypes policy to let me use setHTMLUnsafe(), but in your example you use DOMPurify.sanitize(). If I'm going to sanitise the string why not use setHTML()?

Thanks for this, very useful. Do you know the rationale for removing so much stuff by default?