Inconsistency in HTML entities in attributes in .razor files

[SteveSandersonMS]

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.

[mkArtakMSFT]

@ajaybhargavb do you know what would cost it to fix this?

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ajaybhargavb]

@ajaybhargavb do you know what would cost it to fix this?

I would cost this as M. This could be slightly lower or higher than M depending on how much work we need to do in the parser.

Notes for future reference: This is where the magic happens currently for regular HTML (HtmlContentIntermediateNode). We may want to do something similar for literal attribute value as well. If that is not possible at this layer, then we might need to do this earlier (closer to the parsing layer).