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 look the same if your HTML is error-free.
Note that more and more browsers are being based on the Blink rendering engine; for instance Edge v74 and up are, which accounts for differences between versions of the same program.

Duplicate IDs

Using the same ID value more than once causes browsers to behave differently.

#one:target {color:#E6E6E0; background:#0F0F0A}
..
<p id="one">This is the one.</p>
<p id="one">This is the one.</p>
<p id="one">This is the one.</p>

BrowserResult
Firefox 3.0 .. 83
SeaMonkey 2.12 .. 2.57
Highlights the first paragraph
Chromium 6 .. 87
Safari 5 .. 14
Microsoft Edge 74 .. 86
Konqueror 4
Highlights the first paragraph
Internet Explorer 9 .. 11
Microsoft Edge 15 .. 18
Highlights all paragraphs
Opera 11 .. 12 Highlights the first paragraph

Non-HTML tag names

If you use tag names that are not officially defined HTML, there are browsers that feel free to treat them the way they want.

<style> two:nth-of-type(2) {text-decoration:underline} </style>
..
<one>one</one>
<two>two</two>
<one>one</one>
<two>two</two>

Browser Result
Firefox 3.6 .. 83
SeaMonkey 2.1 .. 2.57
underlines the second <two>
Chrome 6 .. 87
Safari 5 .. 14
Konqueror 4
underlines the second <two>
Internet Explorer 9 .. 11
Microsoft Edge 14 .. 15
underlines the first <two>
Microsoft Edge 16 .. 86 underlines the second <two>
Opera 11 .. 12 underlines the second <two>

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 1 Result 2 Result 3
Firefox 3.0 .. 3.6
SeaMonkey 2.0
Ignores end tagIgnores end tagEnds h4 as if end tag was ok
Firefox 4 .. 83
SeaMonkey 2.1 .. 2.57
Ignores end tagInserts p in addressEnds h4 as if end tag was ok
Chromium 5 .. 6 Ignores end tagInserts p in addressIgnores end tag
Chromium 10 .. 87
Safari 5 .. 14
Konqueror 4(W)
Ignores end tagInserts p in addressEnds h4 as if end tag was ok
Internet Explorer 7 .. 8 Inserts h5 in addressInserts p in addressEnds h4 as if end tag was ok
Internet Explorer 9 .. 11
Microsoft Edge 14 .. 86
Ignores end tagInserts p in addressEnds h4 as if end tag was ok
Opera 9 .. 12 Ignores end tagInserts p in addressEnds h4 as if end tag was ok
Konqueror 3 Ignores end tagIgnores end tagIgnores end tag
Konqueror 4(K) Ignores end tagEnds address; adds pIgnores end tag

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.0 .. 83
SeaMonkey 2.0 .. 2.57
Script ends halfway, rest of script is displayed in the window
Chromium 5 .. 6
Konqueror 3 .. 4(K)
Script runs in its entirety¹
Chromium 10 .. 87
Safari 5 .. 14
Konqueror 4(W)
Script ends halfway, rest of script is displayed in the window
Internet Explorer 7 .. 9 Script runs in its entirety¹
Internet Explorer 10 .. 11
Microsoft Edge 14 .. 86
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
¹ If you remove the comment delimiters, the browser ends the script at </script> too.

Elements in places where they don't belong

<li> outside <ul>

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

<optgroup> outside <select>

<div> Before <optgroup> an opt group </optgroup> and after </div>

<rt> outside <ruby>

<div> Before <rt> a ruby text </rt> and after </div>

Browser With li With optgroup With rt
Firefox 3.0
SeaMonkey 2.0
Block; bullet left of left edgeText put in parent(not recognised)
Firefox 10 .. 83
SeaMonkey 2.7 .. 2.57
Block; bullet left of left edge Collapsed block
content not visible
(not recognised until v36)
Superscripted
Chromium 5 .. 87
Safari 5
Microsoft Edge 15 .. 86
Block. Has paddingBlock
content not visible
Inline
Safari 9 .. 14
Konqueror 4(W)
Block. Has paddingInvisibleInline
Internet Explorer 7 Block (but IE7 ignores the </li> end tag)
Has padding
Text put in parentText put in parent
Internet Explorer 8 .. 9 Block; bullet left of left edgeText put in parentText put in parent
Internet Explorer 10 .. 11
Microsoft Edge 18
Block; bullet left of left edgeBlock
content not visible
Inline
Microsoft Edge 14 Block; bullet left of left edgeInline, with a bold fontInline
Opera 9 .. 11 Block. Has padding.Text put in parent(not recognised)
Opera 12 Block. Has padding.Inline(not recognised)
Konqueror 4(K) Text put in parentText put in parentInline

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:blue">

Browser Result
Firefox 3.0 .. 83
SeaMonkey 2.0 .. 2.57
blue
Chromium 5 .. 87
Safari 5 .. 14
Konqueror 3 .. 4
red
Internet Explorer 7 blue
Internet Explorer 8 .. 11
Microsoft Edge 14 .. 86
red
Opera 9 .. 12 red

Bad link: error in type attribute

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

BrowserResult
Firefox 3.0 .. 83
SeaMonkey 2.0 .. 2.57
Doesn't use stylesheet
Chromium 6 .. 20
Safari 5 .. 9
Konqueror 3 .. 4
Ignores type, shows style normally
Chromium 57 .. 87
Safari 14
Doesn't use stylesheet
Internet Explorer 7 .. 11
Microsoft Edge 14 .. 86
Doesn't use stylesheet
Opera 9 .. 12 Doesn't use stylesheet

Bad link: error in css file type (Quirks mode only)

In Quirks mode, browsers are supposed to ignore the file type of the stylesheet, and to load it anyway. Some browsers are not playing though.

<link rel="stylesheet" href="quirks-19c-css.txt">

BrowserResult
Firefox 3.0 .. 83
SeaMonkey 2.33 .. 2.53
Loads stylesheet
Chromium 15 .. 20
Safari 5 .. 14
Konqueror 4
Loads stylesheet
Chromium 73 Doesn't load stylesheet
Chrome 81 .. 87 Loads stylesheet
Internet Explorer 7 .. 8 Loads stylesheet
Internet Explorer 9 Doesn't load stylesheet
Internet Explorer 11
Microsoft Edge 15 .. 86
Loads stylesheet
Opera 10 .. 12
Vivaldi 1.3
Loads stylesheet

<img> without src

Trying to show an img without a src 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.0 .. 60
SeaMonkey 2.0 .. 2.57
NothingKeeps background, alt text
Firefox 68 .. 83 Keeps size, background. Has borderKeeps background, alt text
Chromium 5 .. 35
Safari 5 .. 14
Konqueror 4(W)
Keeps size, background. Has borderKeeps size, background. Has border
Chromium 55 .. 59 Keeps size, background. Has border Keeps size, background; shows partial alt text. Has border
Chromium 63 .. 64 Keeps size, background. Has borderKeeps background, alt text
Chromium 65 .. 87
Microsoft Edge 74 .. 86
Keeps size, background. Has border Keeps background, alt text; shows broken image icon
Internet Explorer 7 .. 10 Keeps size, background. Has border and a broken image icon Keeps size, background. Has a broken image icon
Internet Explorer 11
Microsoft Edge 14 .. 18
Keeps size, background Keeps size, background; shows partial alt text.
Konqueror 3 .. 4(K) Keeps size, background. Has border and a broken image icon Keeps size, background. Has border and a broken image icon
Opera 9 .. 12 Keeps size, background Keeps size, background, 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 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.

Browser with
Caption
with
Default
with
Inherit
with
Initial
with
Courier 10 Pitch
Firefox 3.0 .. 17
SeaMonkey 2.0 .. 2.14
UsedUsedNot usedUsedNot used
Firefox 20
SeaMonkey 2.17
UsedUsedNot usedNot usedNot used
Firefox 25 .. 83
SeaMonkey 2.22 .. 2.57
UsedNot usedNot usedNot usedNot used
Chromium 6 .. 15
Safari 5
Konqueror 3 .. 4(K)
UsedUsedNot usedUsedNot used
Chromium 20 UsedUsedNot usedNot usedNot used
Chromium 25 .. 87
Safari 9 .. 14
Microsoft Edge 74 .. 86
Konqueror 4(W)
UsedNot usedNot usedNot usedNot used
Internet Explorer 7 UsedUsedUsedUsedUsed
Internet Explorer 8 UsedUsedUsedUsedUsed
Internet Explorer 9 .. 11 Not usedNot usedNot usedNot usedUsed
Microsoft Edge 14 .. 18 Not usedUsedUsedUsedNot used
Opera 9 UsedUsedUsedUsedUsed
Opera 10 UsedUsedNot usedUsedUsed
Opera 11 .. 12 UsedUsedNot usedUsedNot used

Other font names that consist of CSS keywords, such as Unset, are problematic too. So the bottom line is it's best to always use quotes.

For a more in depth article on font names and quotes, you can read my blog post here.

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.

Browser Result
Internet Explorer 9 .. 11 Does not show border
All other browsers tested, including Edge Shows border

Missing parenthesis in CSS function

If you forget the closing parenthesis in a css function such as rgb(...), the results vary.

<p style="background-image:url(pic.png">
Missing parenthesis in url
</p>
<p style="background:linear-gradient(#EC2, #E60">
Missing parenthesis in linear-gradient
</p>

Browser Result with url With linear-gradient
Firefox 10 .. 83
SeaMonkey 2.7 .. 2.57
Pretends all is finePretends all is fine
Chromium 15 .. 20
Safari 5
Konqueror 4
IgnoredIgnored
Chromium 55 .. 87
Safari 14
Microsoft Edge 86
Pretends all is finePretends all is fine
Internet Explorer 11
Microsoft Edge 14
Pretends all is fineIgnored
Microsoft Edge 15 .. 18 Pretends all is finePretends all is fine
Opera 10 .. 12 IgnoredPretends all is fine

Note that this is one area where the rules are clear: if there's an error like that, the style should be ignored. In other words, some browsers used to handle this correctly in the past, but don't any more!

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

Browser Result
Firefox 3.0 .. 83
SeaMonkey 2.0 .. 2.57
Shows ASCII text
Chromium 6 .. 73 (Linux)
Safari 9 .. 14 (iOS)
Konqueror 3
Shows ASCII text
Chrome 5 .. 87 (Windows)
Safari 5
Microsoft Edge 74 .. 86
Konqueror 4
Shows Greek
Internet Explorer 7 .. 11 Shows Greek
Microsoft Edge 14 Shows ASCII text
Microsoft Edge 17 .. 18 Shows Greek
Opera 9 (Linux) Shows ASCII text
Opera 11 .. 12 (Linux) blank
Opera 10 .. 12 (Windows) Shows ASCII text

Note that this is one of the few instances where I found differences between operating systems. 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". Some versions of Linux do interpret the markup and display "Markup in the title" in the title bar, while other versions have "<i>Markup</i> in the title" like in Windows. They all have "<i>Markup</i> in the title" in the tab.

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>
<li>nested comments: 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.
The fourth example is supposed to end at the first --> according to the rules, displaying the following --> on the screen.

BrowserResult 1Result 2Result 3Result 4
Firefox 3.0 .. 3.6
SeaMonkey 2.0
not completenot completecompleteEnds too late¹
Firefox 10 .. 83
SeaMonkey 2.7 .. 2.57
completecompletenot completeEnds properly
Chromium 6
Konqueror 4(L)
not completecompletenot completeEnds properly
Chromium 15 .. 87
Safari 5 .. 14
Konqueror 4(W)
completecompletenot completeEnds properly
Internet Explorer 7 .. 11
Microsoft Edge 14 .. 86
completecompletenot completeEnds properly
Opera 9 not completecompletenot completeEnds properly
Opera 10 .. 11 not completecompletecompleteEnds properly
Opera 12 completecompletenot completeEnds properly

¹ Only in Standards mode though; in Quirks mode; acts just like the other browsers.

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, 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, family
Firefox 3.5 .. 60
SeaMonkey 2.0 .. 2.57
uses size;
default family
ignoredignoredignored
Chromium 6 .. 31
Safari 5 .. 9
Vivaldi TP3
uses size;
default family
uses size, familyignoreduses size, family
Chromium 55 .. 87 uses size;
default family
ignoredignoredignored
Internet Explorer 7 uses sizeuses sizeuses sizeuses size
Internet Explorer 8 uses sizeuses sizeignoreduses size
Internet Explorer 9 .. 11 uses size;
default family
uses size;
default family
ignoreduses size;
default family
Microsoft Edge 14 .. 86 uses size;
default family
ignoredignoredignored
Opera 9 ignoredignoreduses size, weight, familyignored
Opera 10 .. 12 uses sizeignoreduses size, weight, familyignored
Konqueror 4 uses sizeuses size, familyignoreduses size, family

Unofficial colour names

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

BrowserResult 1Result 2
Firefox 3.0 .. 83
SeaMonkey 2.0 .. 2.57
--
Chromium 6 .. 36
Safari 5 .. 9
Konqueror 4(W)
-
Chromium 55 .. 87
Safari 14
Vivaldi 1.12
--
Internet Explorer 8 .. 11
Microsoft Edge 14 .. 86
--
Opera 9 .. 12
Konqueror 4(K) --

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 .. 60
SeaMonkey 2.0 .. 2.57
table is six columns wide
All other browsers tested so far 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 .. 60
SeaMonkey 2.1 .. 2.57
Columns are the specified 100px wide
Chromium 6 .. 20
Safari 5 .. 14
Konqueror 4
Columns have their default widths, ignoring the col definition
Chromium 37 .. 87
Vivaldi TP3
Columns are the specified 100px wide
Internet Explorer 7 Columns have their default widths, ignoring the col definition
Internet Explorer 8 .. 11
Microsoft Edge 14 .. 86
Columns are the specified 100px wide
Opera 9 .. 12 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 10 .. 83
SeaMonkey 2.7 .. 2.57
Ignored; aligned to middle as normal
Chromium 6 .. 87
Safari 5 .. 14
Microsoft Edge 74 .. 86
Konqueror 4
Ignored; aligned to middle as normal
Internet Explorer 8 .. 11
Microsoft Edge 14 .. 18
td is now aligned to top
Opera 9 .. 11 td is now aligned to top
Opera 12 Ignored; aligned to middle as normal

Borders assigned to tr

You shouldn't assign a border property to a tr. It won't have any effect. That is, if you're lucky.
In some circumstances, some browsers will protest by throwing the table out of alignment.

<table style="border:1px solid red" dir="rtl">
<tr style="border:5px solid blue">
<td style="border:1px solid green">Test</td>
</tr>
</table>

BrowserResult
Firefox 3.0 .. 40, 71 and up
SeaMonkey 1.9 .. 2.35
Ignored; no effect
Firefox 41 .. 69
SeaMonkey 2.38 .. 2.57
The td is drawn 10 pixels to the right (2× the width of the tr border)
All other browsers tested so far Ignored; no effect

Backgrounds assigned to tr

Basically the same as above. Table rows don't have backgrounds of themselves, so if you assign a background to a row, it's up to the browsers to decide what to do with it.
Naturally, this may result in some differences.

<table style="width:200px; height:100px">
<tr style="background:url(bkgnd.png)">
<td>One</td><td>Two</td>
</tr>
</table>

BrowserResult
Firefox 3.0 .. 60
SeaMonkey 2.0 .. 2.57
Cells are windows on the tr, showing different parts of the background image
Chromium 15 .. 57
Safari 5 .. 14
Konqueror 4(W)
Acts as if cells inherit the style, all showing the same part of the background image
Chromium 58 .. 87 Cells are windows on the tr, showing different parts of the background image
Internet Explorer 7 Acts as if cells inherit the style, all showing the same part of the background image
Internet Explorer 8 .. 11
Microsoft Edge 14 .. 86
Cells are windows on the tr, showing different parts of the background image
Opera 10 .. 12 Cells are windows on the tr, showing different parts of the background image
Konqueror 4(K) Cells are windows on the tr

Text before the legend in a fieldset

The legend should be the first thing in a fieldset. If you forget that, you get differences in how the browsers display it.

<form action="#">
<fieldset>
Text before legend
<legend>The legend</legend>
Contents of fieldset: <input name="contents"> <input type="submit">
</fieldset>
</form>

BrowserResult
Firefox 52 .. 83
SeaMonkey 2.49 .. 2.57
Looks normal; Text is inside the fieldset
Chrome 63 .. 87
Safari 9 .. 14
Microsoft Edge 74 .. 86
Text is inside the fieldset; behaves as a block
Internet Explorer 5 .. 11
Microsoft Edge 15 .. 18
Text appears above the fieldset
Opera 12 Text is inside the fieldset, followed by text "The legend"
(which does not behave as a legend)

Bad values with calc()

Certain values are illegal in CSS, for instance negative padding values.
In some circumstances, not all browsers play by the rules.

<div style="border: 1px solid; padding-left: calc(0px - 2em);">
This is a div with a negative left padding
</div>

BrowserResult
Internet Explorer 9 .. 11 Applies the negative padding, resulting in content partially out of the confines of the div.
All other browsers tested, including Edge Ignore the error

href=""

Links with href attributes should lead somewhere. And they usually do, but the empty href href="" is an exception.

<a href="">Go nowhere</a>

BrowserResult
Internet Explorer 8 .. 11 Goes to the current directory, i.e. loads the default index.html
All other browsers tested, including Edge Reloads the current file

Using the ::after pseudo-element on void elements

Void elements do not have content by definition, so they can't have pseudo-content either. If you ignore that, the browsers don't all react the same.

<style> area::after {content:'This is the area'; display:inline;} </style>
..
<map name="map1"> <area href="#" coords="0,0,150,75" alt="click here"> </map>
<img usemap="#map1" src="//dummyimage.com/150x75" alt="click here">

BrowserResult
Firefox 3.0 .. 83 Does not show the content
Internet Explorer 8 Does not show the content
Internet Explorer 9 .. 11
Microsoft Edge 15 .. 18
Shows the content
Safari 5 .. 14
Chromium 15 .. 20
Konqueror 4
Does not show the content
Chromium 56 .. 87
Microsoft Edge 86
Shows the content
Opera 10 .. 12 Does not show the content

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