Is your feature request related to a problem? Please describe.

I think it would be helpful if spec-char-escape reported unterminated html entities, for example &copy (with no terminating semicolon). The meaning of an unterminated html entity is ambiguous, so the resulting browser behavior may not be what was intended. The intention may have been to display literally the text, like &copy, but browsers like Chrome display the entity as if it was terminated, in this case ©.

Describe the solution you'd like

The W3C Markup Validation Service used in the related issue (see below) does report unterminated html entities. Here is an example:

<!doctype html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>Hi</title>
    </head>
    <body>
        <p>&copy</p>
    </body>
</html>

The validator reports:

Error: Named character reference was not terminated by a semicolon. (Or & should have been escaped as &.)

[At line 8, column 17](https://validator.w3.org/nu/#cl8c17)

       <p>&copy</p>↩    </body

I think it would be helpful if HTMLHint reported a similar error.

The validator does not seem to report an error if the text after & is not a known html entity. For example, it does not report &a, but it does report &copy and &copyx. ("copy" is a prefix of "copyx".) I'm not sure if HTMLHint should do the same, or to keep the implementation simple should report any text where & is followed by letters, even if they don't match a known entity.

I haven't investigated unterminated html entities that use the &#123 syntax and I haven't thought about how that should behave.

Describe alternatives you've considered

None.

Additional context

spec-char-escape used to assert that & should be changed to &, at least in some cases, for example x & y.

#1382 made spec-char-escape stop checking & because:

W3C Markup Validation Service no longer finds any issues with the uncoded &.

That change actually seems correct to me. There are cases where not escaping & can cause unexpected results, like the one described above, but as far as I know the cases that spec-char-escape was previously checking, like x & y, are not a problem.