Functionality wise: I don't think it's needed.

Performance would be the main reason, IMHO.

On the other hand: performance might well be better using native <template> and clone(true) on the content. It's certainly cleaner than building HTML via strings.

Performance wise, the current behavior shouldn't be significantly different from template, it's primarily an interface difference at that point.

If it's a one-off parse & insert, then it'll be faster than template because it can skip the clone and just adopt the nodes into the new doc. It's still a bit slower than innerHTML because it's still two steps- parse in a separate doc, then adopt & insert into the other doc.

On micro-benchmarks, I've seen measurable impact. But this quickly becomes noise when dealing with larger trees.

This comment was originally written by @simonpai

I could be biased, but I think if Dart recommends using <template> + cloning for performance, it seems a bit too winding. People will just end up polyfilling the API back to what we had as unsafeInnerHtml(). IMHO the API should allow users to do the simplest thing with the simplest call.

This comment was originally written by tomatoactivator...@gmail.com

The current innerHTML sanitizer is very aggressive with what it cleans making the default sanitizer unusable in a lot of instances.

Specific examples are:

1. default dynamic styles (width: 0%)
2. custom data attribute (data-target, data-parent)
3. html5 aria attributes.

Thus for most or many use cases in which you are using innerHTML, you will need to write a custom scrubber or just have a null sanitizer and clean html by other methods. If you choose the latter, you will have to write convoluted statements to get around Dart helper functions that just get in the way. That is a wrong approach in my opinion.

I also want to stress that many uses of innerHTML are not even susceptible to XSS attacks.

This comment was originally written by @tomyeh

It is not only about performance. It is more about the simplicity and clearness.

How many developers really know what sanitization actually does and doesn't do? It just creates an illusion of being safe. But, is it 100% free from XSS attacks? Absolutely not!

IMHO, innerHtml shall be as simple as it shall be. Let developers do their job. The real secure system only comes from people who know what they are doing.

On the other hand, NodeTreeSanitizer is an excellent utility to help developers to get the job done. IMO, it shall be an independent utility, not even part of Element.

I think innerHTML in JavaScript is really great for rapid prototyping and that it should be easier to bypass validation in Dart. Otherwise we make it harder to prototype in Dart than it is in JavaScript.

How many developers really know what sanitization actually does and doesn't do? It just creates an illusion of being safe. But, is it 100% free from XSS attacks? Absolutely not!

The intent of the default policy is to 100% prevent XSS. If it does not, then it is a bug.

Removed Area-HTML label.
Added Area-Library, Library-Html labels.

Removed the owner.
Removed Type-Defect, Priority-Unassigned labels.
Added Type-Enhancement, Priority-Medium labels.