Different error handling in XHTML

The XHTML standard is more strict than the HTML standard - errors that the browser can forgive in an HTML file are often fatal in an XHTML file. But those fatal errors aren't all you have to be on the lookout for.

To demonstrate why you shouldn't have errors in your XHTML source, here are some examples where browsers differ in how they display erroneous XHTML, while they all behave the same if your XHTML is error-free.

Missing end tags at the end of a document

The rules are clear: XML documents must be well formed, or an error is shown.

<div>This document ends abruptly, without properly

(Live example)

Browser Result
Firefox 3.5 .. 60
SeaMonkey 2.0 .. 2.57
Either shows the document as if all is fine, or an error: XML Parsing Error: no element found
(Refresh the frame and both kinds of results will show up at random times)
Chromium 6 .. 35
Midori 0.2 .. 0.4
Safari 5
This page contains the following errors:

error on line 11 at column 49: Extra content at the end of the document¹
Internet Explorer 9 .. 11, Edge The document is shown normally as if everything is fine
Opera 9 .. 12
(if "reparse automatically" is off)
XML parsing failed: syntax error

¹ which isn't true

Attribute case differences in XHTML

XHTML is supposed to be case sensitive. But if it isn't...

<input type="radio" name="group" value="1"/> all OK<br/>
<input type="radio" name="GROUP" value="2"/> uppercase name<br/>
<input type="RADIO" name="group" value="3"/> uppercase type

(Live example)

Browser Uppercase group name Uppercase type
Firefox 3.6
SeaMonkey 2.0
Different groupsCase ignored; shows as radio button
Firefox 17 .. 60
SeaMonkey 2.12 .. 2.57
Different groupsNot a radio button¹
Chromium 6 .. 35
Midori 0.2 .. 0.4
Safari 5
Different groupsNot a radio button¹
Internet Explorer 9 .. 11, Edge Case ignored; used as same groupCase ignored; shows as radio button
Opera 9 .. 12 Case ignored; used as same groupCase ignored; shows as radio button

¹ Not a radio button means the type attribute is not totally ignored (in that case, the input would have been a textbox), but the button looks more like a checkbox. It has an I-beam cursor in Mozilla though. But it still acts like a radio button.

Omitted or truncated DOCTYPE declaration

Omitting the DOCTYPE declaration is technically an error, but in practice it doesn't really make that much difference. The browsers know it's XHTML already, so they display the document accordingly.
Except when you've got entity references in your document.

<p>This is my r&eacute;sum&eacute; with some references.</p>

(Live example)

Since the XML definition contains only a handful of entities, the browser can display XML documents as long as only those entities are referenced. To use the others from the HTML standard, you will need to include the DOCTYPE declaration; as the DTD contains the definitions for them.

IE and Edge don't show anything. All other browsers tested so far handle the above example the same way: display the line if there is a DOCTYPE, or throw an error (or reparse as HTML) if there isn't.

Note that it must be a proper XHTML DOCTYPE; the shorthand HTML5 one doesn't work. A special case, however, is one with only a system identifier (the DTD) without the public identifier.

<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

With this one, Opera v12 and below will display entity references normally, while the other browsers still throw errors.

(Live example)

IE and Edge deserve special mention, in that they don't show error messages, but display the content without the entity references.

Markup in the title

The title of the page is supposed to be plain text, that is, it can't contain markup.

<title>Error test 32: <i>Markup</i> in the title</title>

(Live example)

Most browsers skip the <i>Markup</i>" part and display "Error test 32: in the title" both in the title bar and in the tab.
Opera v12 and below however, displays "Error test 32: Markup in the title" as if the tags weren't there.

Note that with XHTML, unlike the HTML version of this error, the browsers behave the same in Linux and Windows.


The <plaintext> element is obsolete, so using it is an error.

This element still works in HTML, but in XHTML it does nothing except change fonts.

This is normal
<plaintext>This is <i>plaintext</i></plaintext>
And this is normal again!

(Live example)

Now you shouldn't use <plaintext>. Really. But if you see no other way out, the solution is to change the file type to HTML, so that it will work. There's no guarantee that it will remain working for long though.

HTML in <textarea>

The <textarea> element should contain plain text. Now in HTML, there's no problem: its content model is #PCDATA, so if you put unescaped < and > signs in the content, they will be displayed as is. XML doesn't handle them the same way.

<textarea>Textarea with <b>bold</b> text</textarea>

(Live example)

Most browsers skip the <b> element altogether. Opera (v12 and below) and Safari strip off the start and end tags and display the content. IE and Edge parse the content fully and display "bold" in bold.

Sources: various. Some is the result of my own research, some I found all over the web.