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.
The rules are clear: XML documents must be well formed, or an error is shown.
(...)
<body>
<div>This document ends abruptly, without properly
| 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
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
| Browser | Uppercase group name | Uppercase type |
|---|---|---|
| Firefox 3.6 SeaMonkey 2.0 |
Different groups | Case ignored; shows as radio button |
| Firefox 17 .. 60 SeaMonkey 2.12 .. 2.57 |
Different groups | Not a radio button¹ |
| Chromium 6 .. 35 Midori 0.2 .. 0.4 Safari 5 |
Different groups | Not a radio button¹ |
| Internet Explorer 9 .. 11, Edge | Case ignored; used as same group | Case ignored; shows as radio button |
| Opera 9 .. 12 | Case ignored; used as same group | Case 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.
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ésumé with some references.</p>
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.
IE and Edge deserve special mention, in that they don't show error messages, but display the content without the entity references.
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>
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!
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.
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>
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.