RichInStyle.com bug guide - Internet Explorer 5/5.5

This page covers IE 5 and 5.5 There is very little difference between v5 and 5.5, the main difference being :first-line and :first-letter support (and accompanying bugs).

Bugs present only in v5 have a big 5. Those only in 5.5 have a big 55. In the bug summaries below, IE 5 is listed first where they differ.


These have sorted into categories. This should make it easy for to you find whether the propertythat you want to use works.

While it should be easily apparent what area you are using, and therefore which section youshould read, everyone uses Sections A through D, so therefore everyoneshould read these sections.

Bugs by type

Topics to be found in this part of the bug guide

Part 0 - Core issues - everyone must read

Section A - Bugs relating to the attachment of styles topages (5 bugs)

Section B - Bugs relating to the application of styles toelements (10/12 bugs)

Section C - Bugs relating to key concepts (5/3bugs)

Section D - Bugs with units (1 bug)

Part 1 - Topic related issues - must read if youuse the section involved

Section E - Font bugs (13 bugs)

Section F - Text bugs (15/13 bugs)

Section G - Margin and padding bugs (7/4bugs)

Section H - Border bugs (7/6 bugs)

Topics to be found in the other section of this bugguide

Section I - Width and height bugs (4 bugs)

Section J - Float and clear bugs (7/6 bugs)

Section K - Display, cursor and printing bugs (7bugs)

Section L - Positioning bugs (4 bugs)

Part 2 - Element related issues - must read if you usethe elements involved

Section M - Form bugs (10 bugs)

Section N - HR bugs (7 bugs)

Section O - Table bugs (5/4 bugs)

Section P - List item bugs (8 bugs)

Part 3 - Error correction bugs - bugs, butinconsequential unless you produce invalid style sheets

Section Q - Error correction bugs (47/50bugs)

Total bugs (IE 5) = 5 + 10 + 5 + 1 + 13 + 15 + 7 + 7 + 4 + 7 + 7 + 4 + 10 + 7 + 5 + 8 + 47 = 162.

Total bugs (IE 5.5) = 5 + 12 + 3 + 1 + 13 + 13 + 4 + 6 + 4 + 6 + 7 + 4 + 10 + 7 + 4 + 8 + 50 = 157.

Part 0 - Core Issues - MUST READ

Section A - Attachment of style to pages

HTTP link header
Bug 1: unsupported

Internet Explorer 5 won't allow you to link to style sheets via http-equiv LINK. This is anon-serious bug because it is madness to link to style sheets in this way anyway.

Preferred style sheets
Bug 2: treated as persistent

Although preferred style sheets (i.e., those specified using the title attribute) are mutuallyexclusive within titles, and therefore all except the last one should be ignored - IE 5 doesn'tapply this, applying all of them regardless thus treating them as persistent. Again, this isnon-serious because it is pointless to have more than one preferred style sheet on a pageanyway.

Alternate style sheets
Bug 3: unsupported

IE 5 does not support alternate style sheets.

Specificity of style attribute
Bug 4: wrong specificity

The style attribute is given infinite specificity, rather than specificity of 100.Although this is a bug, it should not be fixed.

Bug 5: space required between @import and string

IE 5 incorrectly requires a space between @import and ""; for example, @import"css.css";wouldn't work.

Section B - Application of style to pages

Adjacent sibling combinator and child combinator
Bug 1: Destroyed 5

CSS 1 defined a DELIM token, stating that all characters that couldn't form part ofselector tokens were delimiters. Thus, if IE 5 complied with CSS 1 or 2, it would > and + if itdidn't support them. However, it doesn't and prefers to ignore all unknown delimiting charactersand everything before them, treating this example (BODY + P), for example, as P.

The characters that are affected in CSS 2 are + and >; as CSSexpands, the problems will get worse.

H1 + P {margin-top: 0} /* + and everything that comes before it is ignored, sois considered to be P */
BODY > P {margin-left: 10pt} /* Treated as BODY P */

Bug 2: :link vs. :hover

This is sorted differently from :visited vs. :hover - whereas :visited vs. :hover were sorted for the purposes of hovered over visited textas if they were both :visited:hover, these are sorted as if they were different, with:hover parsed as :link:hover and :link simply as it is.

As a result:

:hover {color: red;
/* background: transparent - initial value; not explicitly stated */}
A:link {color: green;
background: red}

In this example, hovered over unvisited links will be red in color, even though :hover has lowerspecificity than A:link and even though it precedes it for the order sort. They willalso have a red background, since no value is explicitly stated on :hover, so :link provides thevalue.

Bug 3: A:active applied to A:focus

:active is incorrectly applied to tabbed-to links (not a major problem).

What does this all mean?

This means that although IE 5's link formatting is buggy, it is possible to use the bugs toachieve what you want. For example, it is possible to use the bugs to make distinctions betweenhovered over unvisited and visited links, etc. The temptation to exploit this is inevitable, butyou should take care to ensure that your links will look O.K. in future compliant browsers.

Multiple anchor (<A>)pseudo-classes
Bug 4: destroyed

The CSS 2 specification permits this: A:link:hover. IE 5 treats this, which isinvalid at CSS 1, buggily, ignoring the first of the pseudo-classes (in this example, it would beapplied as if it just said A:hover).

Equally, it applies :link:visited as :visited and so on. Although Iwould not encourage invalid CSS, you could take advantage of this to exclude Opera and Netscapefrom link styling, subject only to the warning that Opera will apply :link:link (or any where both are the same), although it will not apply :link:visited.

Bug 5: treated as case-insensitive

It treats ids as case insensitive, whereas the HTML specification states that theyare case sensitive.

Bug 6: treated as case-insensitive

It treats classes as case insensitive, whereas the HTML specification states thatthey are case sensitive.

Bug 7: multiple classes destroyed

Although IE 5 does not support the use of multiple classes (e.g., <P class="onetwo">; matched by P.one.two), it does manage to do a fine job of destroyingthem, by interpreting multiple classes thus: ignore all but the last class, which is applied. E.g.,P.one.two would be parsed as P.two.

Bug 8: Unicode 162-177 not permitted in classes, destroying the page

If you include Unicode characters 162-177 in classes, which are valid, IE 5 will not apply theclass. Furthermore, tokens solely comprised of such characters (or indeed other (truly) invalidcharacters) will destroy the ruleset, applying its content to every element on the page.

Bug 9: unsupported 5

IE 5 does not support :first-line.

Bug 10: unsupported 5

IE 5 does not support :first-letter.

Bug 11: vertical-align not applied 5.5

IE 5.5 does not support vertical-align on :first-letter.

Bug 12: vertical-align not applied 5.5

IE 5.5 does not support vertical-align on :first-line.

Bug 13: :first-line applied behind line box 5.5

Although, as a pseudo-element, first-line selects the text that forms the first line (rather than the line itself), MSIE instead applies background behind the line box.

Bug 14: :first-line makes list marker red5.5

IE 5.5 makes the list marker red when selected with :first-line; this is wrong, since the marker is not part of the element, but is a marker (:before).

Section C - Key concepts

Bug 1: Not supported

The CSS spec permits the use of the backslash for referring to special characters and the like,but IE 5 doesn't support any of these uses. This means that you should avoid using the backslash,unless to eliminate IE from your CSS.

Bug 2: not supported inside simple_selector

In CSS, comments are valid anywhere between tokens, but IE 5 does not support them inside simpleselectors (i.e., it doesn't support them in P/* comment here*/.class).

Bug 3: in @import rules 5

In addition, it does not support them in @import rules, ignoring the import if usedtherein.

Bug 4: not supported following property 5

IE 5 will ignore declarations that have comments immediately following the property (e.g.,color/* comment */ : red).

Bug 5: destroyed immediately after selector 5

IE 5 will ignore selectors that have a comment immediately after the selector (e.g., P/**/{color: red}), applying them as HTML {declarations} (due to another parsing bug, explained below). For example, this example would be applied as HTML{color: red}. This is avoided by preceding them by a space.

Section D - Bugs with units

Bug 1: ex applied as 0.5em

IE 5 applies the ex as 0.5em, which is wrong because the x-height of a font varies from font tofont, and the ex can be as little as 0.3em or as much as 0.6em.

Part 1 - Topic related issues - must read if you use the sectioninvolved

Section E - Font bugs

Font families
Bug 1: font matching

According to the CSS specification, where there is no matching glyph for the characterrequested, a font that does include the glyph should be used instead. While IE applies this forcharacter references (such as &quot;, or &#67;), it does not doso for un-referenced characters, instead applying the glyph that is in the same position in thatfont as the requested glyph normally would be. Thus <SPANstyle="WingDings">H</SPAN> should result in a H, and WingDings should not be usedsince it doesn't contain any H's. This means that you should be wary of specifying fonts that lackthe appropriate glyph for unescaped characters.

Font weights
Bug 2: lighter

This is buggy, not applying the next lightest font; for example, MS Arial, which containsweights corresponding to 100-500, 600, 700-800 and 900, gives a weight of 600 from an inheritedvalue of 900 in IE 5 and thence (correctly) to 100-500.

Bug 3: bolder

This is buggy, not applying the next boldest font; for example, MS Arial, which contains weightscorresponding to 100-500, 600, 700-800 and 900, gives a weight of 700-800 from an inherited valueof 100-500 in IE 5 and thence (correctly) to 900.

Font sizes
Bug 4: initial value

Although the CSS specification states that medium is the initial value of font-size, IE does not apply this, and makes small the initial value. This is a shamebecause IE's implementation of the font size keywords is otherwise excellent, but this one bugruins it.

Font styles
Bug 5: oblique destroyed

Font-style: oblique is applied as font-style: italic, which is wrong - if one wanted oblique,failing which italic, one should write font-style: italic; font-style: oblique.

Font variants
Bug 6: small-caps

Font-variant: small-caps doesn't apply a small-caps font, even if one is available, but isapplied as text-transform: uppercase and a smaller font.

Bug 7: normal

If font-variant: normal is applied to text that has been text-transformed, the text-transform isignored. Note that this does not apply to inherited font-variant: normal, but it does apply toinherited text-transform. E.g., it applies to:

<div style="text-transform: capitalize">
<p style="font-variant: normal">
Test text

But not to:

<div style="font-variant: normal">
<p style="text-transform: capitalize">
Test text

UI fonts
Bug 8: line-height and font-variant not reset

When a user font is specified (e.g., font: caption), it should reset all font values to normal,and should also reset line-height, and if the OS doesn't have values for these for the UI font,they should be set to their initial value. In IE, they only reset the values set by the OS - weight(i.e., boldness), style (i.e., italicity), size and family, but do not reset line-height orfont-variant. This means that you should specify line-height explicitly, and must specifyfont-variant explicitly if you use font-variant: small-caps.

Bug 9: hyphenated user fonts unsupported unless hyphen omitted

IE 5 only supports the hyphenated user fonts (viz. small-caption, status-bar, message-box) if you(illegally) omit the hyphen. IE 5.5 on the other hand, supports both, but should only support the legal method.

While this is definitely a bug (albeit one caused by a change to CSS), it demonstrates theimportance of consistency - CSS does not hyphenate user colors, but it does hyphenate user fonts;that there should be some confusion is hardly surprising. This doesn't actually cause any problemsat all, provided you do this:

P {font: smallcaption; /* For IE 5 */
font: small-caption; /* For compliant UAs - doesn't mess up IE, since it interprets it as afont-family, but correctly ignores the declaration since font-size (required, else invalid) isomitted)

Line heights
Bug 10: images

When an image is inline, it should increase the line-height if needed to fit it onthe line, but it should not decrease it. IE ignores this, and all line boxes that have inlineimages automatically and irreversably have line-height: normal.

Note: normal

Normal does not apply a constant <number>, as it probably should. Forexample, given font-size: 10px, line-height: normal is applied as 1.275<= n < 1.325, whereas font-size: 20px applies 1.1375 <= n < 1.1625. Thisisn't noted as a bug because the spec doesn't say that this wrong; however, I think it is.

Bug 12: line box height incorrectly calculated

IE 5 doesn't calculate the size of line boxes in the correct manner - it makes them equal insize to the largest value for line-height in the line box, whereas correct would be to make it fromthe top of the top inline box to the bottom of the bottom one.

Although this is technically a bug, it is a better approach than the 'correct' one, and as suchshould not be changed - it certainly won't cause anyone any problems.

Bug 13: minimum background height on a line box = font-size 5

When you set line-height to less than font-size, IE 5 will correctly honor the line-heightinsofar as the line box will be the specified height, but it will not correctly honor thebackground - it does not draw backgrounds that are smaller than font-size, so for example <Pstyle="background: red; line-height: 4px; font-size: 16px"> would result in a background in eachline box that would be 16 pixels high.

Section F - Text bugs

Bug 1: Large text-indents

Where a text-indent is specified that exceeds the element's width, IE 5 increases thepadding-right of the element to compensate. This is unlikely to be a problem since text-indents donot typically exceed a few percent.

Bug 2: inheritance 5

Text-decoration is inherited rather than applied (as the spec states) as though descendantelements should have the text-decoration of their parent (i.e., the same color, thickness, etc.).This means that the text-decoration will be the color of the descendant rather than of theancestor, and also that text-decoration: none will work on descendant elements to suppress theancestor's text-decoration, which is clearly a nonsense.

Bug 3: inheritance 5

IE incorrectly 'inherits' text-decoration. For example, P {text-decoration: underline} P.class{text-decoration: line-through} would apply both of them to the P.class.

This bug, although highly unlikely to occur, can be avoided as follows:

P {text-decoration: whatever}
P.class {text-decoration: whatever-else}
P {text-decoration: whatever}
P.class {text-decoration: none}
P.class {text-decoration: whatever-else}
N.B., not:
P.class {text-decoration: none;
text-decoration: whatever-else}

This bug (and its workaround) would also apply where an element had both a class and an id, andthey had differing text-decorations.

Bug 4: inherited to block elements

IE 5 inherits text-decoration to block elements, whereas the CSS spec states that is onlyinherited to inline descendants.

Bug 5: text-decoration: blink

This doesn't work.

Bug 6: text-decoration: blink not ignored

IE 5 does not ignore text-decoration: blink correctly. For example, given text-decoration:underline; text-decoration: blink, it should ignore the blink declaration because it doesn'tsupport it and apply the underline, but it doesn't, applying no text-decoration at all. Note thatthis is in a sense non-serious because it is highly unlikely that anyone would have this kind ofdeclaration anyway. This bug also means future values of text-decoration will probably causeproblems.

Bug 7: doesn't work

This doesn't work.

Bug 8: only sub and super work on text

Sub and super are the only supported values on text.

Bug 9: vertical-align: middle

This aligns the middle of the element's box with the baseline of the parent box, not thebaseline plus half the x-height as it should. (In IE 5.5 it aligns with an arbitrary, rather than calculated middle.)

Bug 10: vertical-align: super and sub 5

Not supported on images or form elements.

Bug 11: vertical-align: text-bottom

Only aligns with the baseline, not the bottom as it should.

Bug 12: length and % unsupported

IE 5 does not support vertical-align lengths or percentages.

Bug 13: vertical-align: super and sub increase background height

Vertical-align: super and sub increase the height of the background. For example, <SPANstyle="vertical-align: super; background: blue"> would (correctly) raise the baseline of theSPAN to the correct position for superscripts, but it would draw the background from the bottom ofwhere it would orginally have been to the top of where it ends up.

Bug 14: doesn't work

White-space doesn't work.

Bug 15: ƒ uppercased results in nothing

When uppercased, ƒ results in a missing character glyph. This is incorrect because ifcharacter cannot be transformed, it should be left as-is.

Section G - Margin and padding bugs

Margins and padding in general
Bug 1: inline elements 5

Margins and padding don't work on inline text elements, but margins (not padding) do work onIMG, and both work on FORM elements.

Bug 2: hspace and vspace not equivalenced by margin properties

Although the hspace and vspace HTML attributes (valid on the OBJECT and IMG elements) should beequivalenced by the margin properties, in IE 5 they are not, being applied in addition tothe margin rather than instead of it.

Bug 3: padding not applied to empty elements 5

Padding is not applied to empty elements.

Margin-left and margin-right
Bug 4: auto treated as 0

If you set margins to auto, they are replaced with 0, which is wrong when both margin-left and margin-right are auto or when either margin-left ormargin-right is set to auto and width is set to a value other than auto, or when margin-right isnot 0 and margin-left is auto.

Bug 5: negative margin-rights that overflow the canvas

If you set a negative margin right on an element and it causes its right edge to go to the rightof the right edge of the canvas, the canvas will not be extended by adding or extending a scrollbar, and hence the content will be cut off.

Bug 6: margin-right not ignored when width set

When width is set, since IE 5 doesn't support auto, it should ignore margin-right,setting it to such a value as to make it fit the containing block, but doesn't, applying itregardless.

Bug 7: on DIV with background-color 5

When a DIV has padding-top or padding-bottom set on it, its first andlast child's backgrounds will color in the padding. For example:

<div style="padding: 2em;">
<P style="background: red;">
<P style="background: green;">

Would set DIV's padding-top to red, and its padding-top to green. Thisis of zero consequence unless either element has a border.

Note that the right and left padding would (correctly) be transparent.

Section H - Border bugs

Bug 1: Borders on BODY

Borders are unusable on BODY, being applied outside of the scroll bar, thus meaning that theborder is drawn outside of the scroll bar.

As a result, they should be avoided.

Bug 2: margins on BODY when borders have been set

According to the CSS spec, margins are outside of borders. IE 5 does not apply this, applyingmargins inside borders on BODY.

Bug 3: borders on HTML

Borders are badly broken on HTML as well, though in a different way. They are only applied whenBODY does not have a border (i.e., BODY's border is renderd on top), and the rest of the time theyare applied in a buggy way that destroys the page.

As a result, they should be avoided.

Bug 4: unsupported on inline elements 5

IE 5 does not support borders on inline non-replaced elements; however, it does support them onreplaced elements.

Border widths
Bug 5: border-width deducted from width

Where a border width is set and width is explicitly set, it is deducted from the element'swidth, rather than added to the margin-right. Whilst this is not likely to be significant when youhave a thin border, it will be when you set a big one, as is likely with 3d borders.

Border styles
Bug 6: 3D styles rendered as solid when border-color is dark

Because IE applies the 3D border styles by applying a darker section, all of the followingborder styles will appear as solid when the border color is black or very dark:

Bug 7: dotted and dashed unsupported 5

The dotted and dashed border styles are not supported, being rendered as solid.

Next section

Because this document is very long, it has been split into two parts to reduce download times.To continue to the next section, which considers widths and heights, tables, lists, floats, formsand more, click here.