Christian Johansen

> This would mean if you plan to use innerHTML you have to not create a text node and use innerHTML for that text too. This is just one of...

> I think the reason why is I'm unclear on "real" use cases where this would happen. It feels more like exploratory notes from someone doing work on vdom and...

> I get that it's easy to trigger, but I'm struggling to understand at the application level why someone would invoke this usage pattern. Because it's so easy to trigger,...

> I'm coming from the standpoint of needing to not break the world for everyone relying on snabbdom, today. I have the utmost respect for this mindset! Breaking changes helps...

> I did not re-write anything. I asked for a real world instance of the problem from an app's codebase to look at, and then did my best to give...

One last point re: guarding against reuse of elements. If done too conservatively, components like this: ```js function niceTitle({titleMarkup, title}) { return snabbdom.h('h1', { props: titleMarkup ? {innerHTML: titleMarkup} :...

> IMO, innerHTML is an escape hatch and that if you decide to use it for some reason you need to make sure it does not interfere with snabbdom yourself....

> At least in snabbdom, one shouldn't be injecting large chunks of raw HTML into a virtual DOM tree because it wasn't designed to work that way and will probably...

After looking into this some more I realize that the initial report is a little inaccurate. The problem is that calling `toVNode` with a document fragment created from only a...

Since you ask, I tried a few more 😁 Seems it doesn't sit well with Safari. I can look into that tomorrow (it's bedtime over here in Norway) and see...