Compare the following:

<h1 title="This is nice&trade;">A</h1>
<h1 title="This is nice&trade;">B @DateTime.Now</h1>

In the first case, the tooltip displays This is nice™, whereas in the second case it displays This is nice™.

The reason for the difference is that, when we introduce the element as markup, it goes through the HTML parser which implicitly converts ™ to ™, whereas when we build the element dynamically we assign the attribute value using setAttribute which assumes the value already contains the desired, unencoded string.

As far as I'm aware, this only applies to HTML entities, and not to any other syntax such as embedding elements or comments inside attribute values, since those latter cases aren't actually valid.

I'm not certain what the desired solution would be. We definitely don't want to run literally all attribute values through the full HTML parser at runtime each time we set an attribute value, partly because perf and partly because we don't actually want a "full HTML parser" - we just want an "HTML entities to unicode" converter.

We might want something like:

• For string literals in the source, perform HTML-entity-to-unicode conversion during compilation
• For dynamic values at runtime, leave the existing behavior so it's equivalent to MVC/Razor Pages which proactively encode the attribute value before emitting it

We also need to check that prerendering produces the same effect as whatever we choose.