HTML and CSS Reference
In-Depth Information
For the greatest safety, the markup should have had the special characters encoded like so:
<p>
A silly math statement ahead x
<
y
>
z is not dangerous to
validation.
</p>
We note that this example is fairly contrived and often just an extra space will allow the
validator (and browser) to tokenize the text correctly. For example,
<p>
A silly math statement ahead x < y > z is dangerous to validation?
</p>
will likely validate. The loose enforcement of special character handling is both a blessing
and a curse. It leads to sloppy usage and surprising bugs.
Sloppy syntax is troubling because interpretation may vary browser to browser.
Consider the point of case sensitivity of named entities in browsers. Named entities are
supposed to be case sensitive. For example,
à
and
À
are two different
characters.
Now given this fact, what should a browser do when faced with
<p>
&POUND; and £
</p>
Apparently it treats the first as text and the second as an entity.
But does that hold for all characters? Apparently not—some entities like
©
are
generally case insensitive, while others like
™
may vary by browser, and others like
¥
will always be case sensitive.
Initial drafts of HTML5 attempted to formalize what named entities should be case
insensitive; these drafts focused on the commonly used and supported entities. The current
list of what should be case-insensitive named entities is shown in Table A-1.
Best practice, however, would be not to rely on case insensitivity of named entities, it is
still inconsistent. In general, lax syntax enforcement and permissive interpretation of
entities in browsers just leads to all sorts of small quirks. Consider
<p>
"E; and "e;
</p>
