Examples: different error handling

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

Start/end tag mismatch

Reaction to mismatched tags varies greatly and depends on what the tags are.

Test 1: address, h5

Normal text
<address>address with h5 end tag</h5>
Normal text

Test 2: address, p

Normal text
<address>address with p end tag</p>
Normal text

Test 3: h4, h5

Normal text
<h4>h4 with h5 end tag</h5>
Normal text

Browser Result 1Result 2Result 3
Firefox 3.0 .. 3.6
SeaMonkey 2.0
Ignores end tag Ignores end tag Ends h4 as if end tag was ok
Firefox 4 .. 30
SeaMonkey 2.1 .. 2.47
Ignores end tag Inserts p in address Ends h4 as if end tag was ok
Chromium 5 .. 6
Midori 0.2
Ignores end tag Inserts p in address Ignores end tag
Chromium 10 .. 35
Midori 0.4
Safari 5
Ignores end tag Inserts p in address Ends h4 as if end tag was ok
Internet Explorer 7 .. 8 Inserts h5 in address Inserts p in address Ends h4 as if end tag was ok
Internet Explorer 9 .. 11, Edge Ignores end tag Inserts p in address Ends h4 as if end tag was ok
Opera 9 .. 12 Ignores end tag Inserts p in address Ends h4 as if end tag was ok
Konqueror 3 Ignores end tag Ignores end tag Ignores end tag
Konqueror 4 Ignores end tag Ends address; adds p Ignores end tag

Staggered tag mismatch: span partially in p, partially outside

<p>Before span <span>in span</p> after p</span> and after span.

(In this example, the p is red and the span is underlined, so you can see where each ends.)

Browser Result
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
Span ends at </p>
Chromium 5 .. 35
Midori 0.2 .. 0.4
Safari 5
Span ends at </p>
Internet Explorer 7 .. 8 Span ends with </span>, paragraph break in span
Internet Explorer 9 .. 11, Edge Span ends at </p>
Opera 9 .. 10 Span ends with </span>, paragraph break in span
Opera 11 .. 12 Span ends at </p>
Konqueror 3 .. 4 Span ends at </p>

Text "</script>" in JavaScript

<p id="test">You should see only this line (with end tag).</p>
<script type="text/javascript"> <!--
var text = document.createTextNode('</script>');
document.getElementById('test').appendChild(text);
//-->
</script>

Browser Result
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
Script ends halfway, rest of script is displayed in the window
Chromium 5 .. 6
Midori 0.2
Script runs in its entirety¹
Chromium 10 .. 35
Midori 0.4
Safari 5
Script ends halfway, rest of script is displayed in the window
Internet Explorer 7 .. 9 Script runs in its entirety¹
Internet Explorer 10 .. 11, Edge Script ends halfway, rest of script is displayed in the window
Opera 9 .. 11 Script runs in its entirety¹
Opera 12 Script ends halfway, rest of script is displayed in the window
Konqueror 3 .. 4 Script runs in its entirety¹
¹ If you remove the comment delimiters, the browser ends the script at </script> too.

<li> outside <ul>

<div> Before <li> a list item </li> and after </div>

Browser Result
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
Shows as block; bullet left of left edge
Chromium 5 .. 35
Midori 0.2 .. 0.4
Safari 5
Shows as block. Has padding.
Internet Explorer 7 Shows as semi-block (line break before, but not after). Has padding.
Internet Explorer 8 .. 11, Edge Shows as block; bullet left of left edge
Opera 9 .. 12 Shows as block. Has padding.
Konqueror 3 Shows as block. Has padding.
Konqueror 4 Tags are ignored; text shown inline

Note that although the list items have padding or margin in many browsers, that is not the case when in a ul!

3-digit color attribute in <font> element

<font color="#0D0">So this is #0D0</font>

Browser Result
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
Shows color as if it was #00DD00
Chromium 5 .. 35
Midori 0.2 .. 0.4
Safari 5
Shows color as if it was #00DD00
Internet Explorer 7 .. 11 Ignores color declaration
Microsoft Edge Shows color as if it was #00DD00
Opera 9 .. 11 Ignores color declaration
Opera 12 Shows color as if it was #00DD00
Konqueror 3 .. 4 Shows color as if it was #00DD00

Note: as <font> is not part of HTML5 or HTML 4.01 Strict, this test was done using HTML 4.01 Transitional.

Font color with rgb

<font color="rgb(0,99,0)">color = rgb(0,99,0)</font>

Browser Result
Firefox 3.0 .. 3.6
SeaMonkey 2.0
Ignores color
Firefox 4 .. 30
SeaMonkey 2.1 .. 2.47
Acts as if color = #B09900
Chromium 5 .. 10
Midori 0.2 .. 0.4
Safari 5
Interprets color as rgb(0,99,0)
Chromium 15 .. 35 Acts as if color = #B09900
Internet Explorer 7 .. 11, Edge Interprets color as rgb(0,99,0)
Opera 9 .. 11 Acts as if color = #00B000
Opera 12 Acts as if color = #B09900
Konqueror 3 .. 4 Interprets color as rgb(0,99,0)

Contradictory attributes and styles

When an element's attribute values differ from the CSS styles for the element, the CSS styles usually take preference over the attribute.
Usually, but not always.

<hr color="red" style="color:cyan">

Browser Result
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
cyan
Chromium 5 .. 35
Midori 0.2 .. 0.4
Safari 5
red
Internet Explorer 7 cyan
Internet Explorer 8 .. 11, Edge red
Opera 9 .. 12 red
Konqueror 3 .. 4 red

Empty width attribute

<img src="pic.gif" alt="" width="">

BrowserResult
Internet Explorer 7 .. 10 Treats image as if width = "1"
All other browsers tested so far, including IE11 Ignores width, displays image normally

Bad link: error in type attribute

<link rel="stylesheet" href="error-19a-css.css" type="text/html">

BrowserResult
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
Doesn't use stylesheet
Chromium 6 .. 35
Midori 0.2 .. 0.4
Safari 5
Ignores type, shows style normally
Internet Explorer 7 .. 11, Edge Doesn't use stylesheet
Konqueror 3 .. 4 Ignores type, shows style normally
Opera 9 .. 12 Doesn't use stylesheet

Bad link 2: bad file type for the css

<link rel="stylesheet" href="error-19c-css.txt" type="text/css">

BrowserResult
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
Doesn't use stylesheet
Chromium 6 .. 35
Midori 0.2 .. 0.4
Safari 5
Doesn't use stylesheet
Internet Explorer 7 .. 8 Ignores type, shows style normally
Internet Explorer 9 .. 11, Edge Doesn't use stylesheet
Opera 9 .. 11 Ignores type, shows style normally
Opera 12 Doesn't use stylesheet
Konqueror 3 Ignores type, shows style normally
Konqueror 4 Doesn't use stylesheet

Of the browsers that don't use the stylesheet, surprisingly they all do use it in quirks mode.

Bad link 3: encoding mismatch

<link rel="stylesheet" href="error-19d-css16.css" type="text/css">

If the HTML file is encoded as UTF-8, and the CSS file is UTF-16, and the link doesn't explicitly specify an encoding, this happens:

BrowserResult
Firefox 3 .. 26
SeaMonkey 2.0 .. 2.47
Doesn't use stylesheet
Chromium 15 .. 31
Midori 0.2 .. 0.4
Safari 5
Doesn't use stylesheet
Internet Explorer 7 .. 11, Edge Doesn't use stylesheet
Opera 10 .. 12 Detects encoding, shows style normally
Konqueror 4 Doesn't use stylesheet

<img> without src

Trying to show an img without a scr attribute

<img style="width:30px; height:30px; background:lime"><br> <img style="width:30px; height:30px; background:lime" alt="square">

Browser Without alt With alt
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
NothingKeeps background. Shows alt text
Chromium 5 .. 35
Midori 0.2 .. 0.4
Safari 5
Keeps size, background. Has borderKeeps size, background. Has border
Internet Explorer 7 .. 10 Keeps size, background. Has border and a broken image iconKeeps size, background. Has a broken image icon
Internet Explorer 11 Keeps size, backgroundKeeps size, background. Shows alt text.
Konqueror 3 .. 4 Keeps size, background. Has border and a broken image iconKeeps size, background. Has border and a broken image icon
Opera 9 .. 12 Keeps size, backgroundKeeps size, background and shows alt text. Has border

Font names without quotes

If you have a font name which happens to be a CSS keyword, or which contains characters that are not letters, you get inconsistencies when you omit the quotes around the name.

<div style="font:1.5em Caption">This is 1.5em Caption</div>
<div style="font:1.5em Default">This is 1.5em Default</div>
<div style="font:1.5em Inherit">This is 1.5em Inherit</div>
<div style="font:1.5em Initial">This is 1.5em Initial</div>
<div style="font:1.5em -moz-field">This is 1.5em -moz-field</div>
<div style="font:1.5em Courier 10 Pitch">This is 1.5em Courier 10 Pitch</div>

Which style rules are used and which are not, is evident by the larger text size: when the style is considered OK, the "1.5em" part is applied, even if a font with that name can't be found.
"Courier 10 Pitch" is a real font, by the way, and if you're wondering, no, it's not the spaces in the name that cause the problems.

Browserwith
Caption
with
Default
with
Inherit
with
Initial
with
-moz-field
with
Courier 10 Pitch
Firefox 3 .. 17
SeaMonkey 2.0 .. 2.17
UsedUsedIgnoredUsedUsedIgnored
Firefox 25 .. 30
SeaMonkey 2.22 .. 2.47
UsedIgnoredIgnoredIgnoredUsedIgnored
Chromium 6 .. 15
Midori 0.2
Safari 5
Konqueror 3 .. 4
UsedUsedUsedUsedUsedIgnored
Chromium 20
Midori 0.4
UsedUsedIgnoredIgnoredUsedIgnored
Chromium 25 .. 35 UsedIgnoredIgnoredIgnoredUsedIgnored
Internet Explorer 7 UsedUsedUsedUsedUsedUsed
Internet Explorer 8 UsedUsedUsedUsedIgnoredUsed
Internet Explorer 9 .. 11 IgnoredIgnoredIgnoredIgnoredIgnoredUsed
Microsoft Edge IgnoredUsedUsedUsedIgnoredUsed
Opera 9 UsedUsedUsedUsedUsedUsed
Opera 10 UsedUsedIgnoredUsedUsedUsed
Opera 11 .. 12 UsedUsedIgnoredUsedUsedIgnored

Missing space before a # in CSS

There is a border around <span style="border:1em outset#777">this span</span>.

If you forget the space in the shorthand property, the results vary.

BrowserResult
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
Shows border
Chromium 5 .. 35
Midori 0.2 .. 0.4
Safari 5
Konqueror 3 .. 4
Shows border
Internet Explorer 9 .. 11 Does not show border
Microsoft Edge Shows border
Opera 9 .. 12 Shows border

Using ASCII characters with the Symbol font

The Symbol font is meant for displaying several Greek and mathematical symbols. However, there are right ways and wrong ways to use it. Long ago, the right way was to set this as your display font and write ASCII letters. So if you wanted "Η γρηγορη καφε αλεπου πηδαει πανω απο ενα τεμπελης σκυλι.", you wrote something like

<div style="font-family:'Symbol'">
H grhgorh kafe alepou phdaei panw apo ena tempelhV skuli.
</div>

These days, if you try that, it will come out as

BrowserResult
Firefox 3 .. 30
SeaMonkey 2.0 .. 2.47
Shows ASCII text
Chromium 6 .. 31 (Linux)
Midori 0.2 .. 0.4
Shows ASCII text
Chromium 5 .. 35 (Windows)
Safari 5
Shows Greek
Internet Explorer 7 .. 11 Shows Greek
Microsoft Edge Shows ASCII text
Opera 9 (Linux) Shows ASCII text
Opera 11 .. 12 (Linux) blank
Opera 10 .. 12 (Windows) Shows ASCII text
Konqueror 3 Shows ASCII text
Konqueror 4 Shows Greek

Note that this is one of the few instances where I found differences between Linux and Windows. Maybe we shouldn't be using Symbol at all any more.

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)

The results are remarkably similar across browsers, however they differ between operating systems: in Windows, all browsers display "<i>Markup</i> in the title". In Linux it depends; some version do interpret the markup and display "Markup in the title" in the titlebar, while others have "<i>Markup</i> in the title" like in Windows. They all have "<i>Markup</i> in the title" in the tab.

Bad value for align attribute

<table>
<caption align="none">This is the caption</caption>
<tr><td>and this is the content.</td></tr>
</table>

BrowserResult
Firefox 3 .. 26
SeaMonkey 2.0 .. 2.47
Ignores the bad value
Chromium 6 .. 31
Midori 0.2 .. 0.4
Safari 5
Ignores the bad value
Internet Explorer 7 .. 11, Edge Ignores the bad value
Opera 10 .. 12 Takes the opportunity to put the caption below the table
Konqueror 4 Ignores the bad value

Note: as align is deprecated, this test was done using HTML 4.01 Transitional.

Dashes in comment

Note that the definition of how comments are parsed is different for HTML5 than it was for SGML-based HTML, in the old days. So be careful with them: what is an error today, like <!-- comment -- >, was perfectly acceptable in SGML. And reversely, <!-- comment-- --> is OK to modern browsers now, but was treated as an incomplete comment before. To play it safe, play by the rules: don't use two dashes in a row and don't have spaces before the closing >.

However, the browsers don't all play by the rules; both the modern ones that are HTML5-aware and the old ones that only know about SGML differ in what they consider correct or not.

<ol>
<li>too few dashes: before <!--> and after <br title=--> </li>
<li>too many dashes: before <!-- -- --> and after <br title=--> </li>
<li>too many spaces: before <!-- -- > and after <br title=--> </li>
</ol>

The browser will display "before and after" if it sees a complete comment. If it doesn't, it only displays "before", because the text "and after" will be part of the comment.
Note that the <br title=--> is an error recovery device in case the comment was incomplete: this will end it. Otherwise it's just a line break with a title.

BrowserResult 1Result 2Result 3
Firefox 3.0 .. 3.6
SeaMonkey 2.0
incompleteincompletecomplete
Firefox 17
SeaMonkey 2.7 .. 2.47
completecompleteincomplete
Chromium 6
Midori 0.2
incompletecompleteincomplete
Chromium 15 .. 31
Midori 0.4
Safari 5
completecompleteincomplete
Internet Explorer 7 .. 11, Edge completecompleteincomplete
Opera 10 .. 11 incompletecompletecomplete
Opera 12 completecompleteincomplete
Konqueror 4 incompletecompleteincomplete

Wrong parameter order in font shorthand

The parameters in the font style are supposed to be in this order: font-style font-variant font-weight font-size/line-height font-family. See the W3C Fonts page. Most of them are optional, so you can leave them out if you want, but you cannot put them out of order. A font style with parameters in the wrong places is an error and will be ignored.

That is, it will be ignored in theory. In practice, browsers differ in what they consider errors and what they don't.

<ol style="font-size:13px; font-style:normal; font-family:serif>
<li style="font:18px normal monospace">18px normal monospace</li>
<li style="font:18px normal 'Arial'">18px normal 'Arial'</li>
<li style="font:italic 18px 700 'Arial'">italic 18px 700 'Arial'</li>
<li style="font:18px italic 'Arial'">18px italic 'Arial'</li>
</ol>

BrowserResult 1Result 2Result 3Result 4
Firefox 3.0 uses sizeignoredignoreduses size and family
Firefox 3.5 .. 24
SeaMonkey 2.0 .. 2.47
uses size;
default family
ignoredignoredignored
Chromium 6 .. 31
Midori 0.2
Safari 5
Vivaldi TP3
uses size;
default family
uses size and familyignoreduses size and family
Internet Explorer 7 uses sizeuses sizeuses sizeuses size
Internet Explorer 8 uses sizeuses sizeignoreduses size
Internet Explorer 9 .. 11, Edge uses size;
default family
uses size;
default family
ignoreduses size;
default family
Opera 10 .. 12 uses sizeignoreduses size, weight and familyignored
Konqueror 4 uses sizeuses size and familyignoreduses size and family

Unofficial colour names

<div style="color:Copper">Copper</div>
<div style="color:LightSlateBlue">LightSlateBlue</div>

BrowserResult 1Result 2
Firefox 3.0 .. 26
SeaMonkey 2.25 .. 2.47
--
Chromium 15 .. 36
Midori
Safari 5
Vivaldi TP3
-
Internet Explorer 8 .. 11, Edge --
Opera 10 .. 12
Konqueror 4 --

More <col>s than columns

If a table has a number of columns defined with <col>, but there are fewer columns in the body of the table, there is a mismatch.

<table>
<col span="6" width="70">
<tr><td>one</td><td>two</td><td>three</td></tr>
</table>

BrowserResult
Firefox 3.6 .. 36
SeaMonkey 2.0 .. 2.47
table is six columns wide
Chromium 15 .. 44
Midori 0.4
Safari 5
Vivaldi TP3
table is three columns wide
Internet Explorer 7 .. 11, Edge table is three columns wide
Opera 10 .. 11 table is three columns wide
Konqueror 4 table is three columns wide

<col>s after the table content

Column definitions in tables should always go before the first table row. If you forget that...

<table>
<tr><td>one</td><td>two</td><td>three</td></tr>
<col span="3" width="100">
</table>

BrowserResult
Firefox 3.6 .. 25
SeaMonkey 2.33 .. 2.47
Columns are the specified 100px wide
Chromium 20
Midore 0.4
Safari 5
Columns have their default widths, ignoring the col definition
Chromium 37 .. 44
Vivaldi TP3
Columns are the specified 100px wide
Internet Explorer 7 Columns have their default widths, ignoring the col definition
Internet Explorer 8 .. 11, Edge Columns are the specified 100px wide
Opera 11 Columns have their default widths, ignoring the col definition
Konqueror 4 Columns have their default widths, ignoring the col definition

Attributes with bad values

Browsers usually ignore bad attribute values altogether. But apparently not always!

<table border="1">
<tr>
<td valign="botto" height="60">This is a bad td</td>
</tr>
</table>

BrowserResult
Firefox 15 .. 43
SeaMonkey 2.12 .. 2.47
Ignored; aligned to middle as normal
Chromium 20 .. 51 Ignored; aligned to middle as normal
Internet Explorer 8 .. 11, Edge td is now aligned to top
Safari 5 Ignored; aligned to middle as normal
Opera 11 td is now aligned to top
Konqueror 4 Ignored; aligned to middle as normal

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