Well, you’ve actually defined multiple goals for this component. The obvious two are:
- Ability to handle untrusted data
- Ability to embed components in-line.
For situations where only one of the features is required, the others may sometimes get in the way. So, depending on the situation, some conflicts (between those goals) will be inevitable.
In non-UI components, one would re-factor the features so that they could stand alone, allowing them to be combined – or not – via regular programming-language features (e.g., inheritance). But I recognize that that can be a lot harder with UI components!
In any case, for fuller HTML, there’s always the fallback of Custom HTML. Of course, then you don’t get the ability to use in-line components. But then, I would not be surprised that it was the “sanitization” that made the component-embedding practical in the first place.
Frankly, I’m delighted to see this. In the desktop world, I’ve seen only one visual component library that offered anything comparable, and it was RichText only.
This immensely simplifies layout development, and makes it accessible to everyday folks. Not everyone can take the time to work out a 5-deep hierarchy of nested containers (when necessary) to accomplish their goals!