Tutorials Bugs Masterclass Free stuff Test pages Proposals

RichInStyle.com bug guide - Internet Explorer 4

Bugs (continued)

Bugs by type

Topics to be found in the other part of the bug guide

Part 0 - Core issues - everyone must read

Section A - Bugs relating to embedding, linking and parsing style sheets (26 bugs)

Section B - Bugs with units (3 bugs)

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

Section C - Font bugs (15 bugs)

Section D - Text bugs (16 bugs)

Section E - Color and background bugs (1 bug)

Section F - Margin and padding bugs (11 bugs)

Section G - Border bugs (8 bugs)

Topics to be found in this section of the bug guide

Section H - Width and height bugs (6 bugs)

Section I - Float and clear bugs (14 bugs)

Section J - Display, cursor and printing bugs (9 bugs)

Section K - Positioning bugs (5 bugs)

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

Section L - Form bugs (12 bugs)

Section M - HR bugs (8 bugs)

Section N - Table bugs (10 bugs)

Section O - List item bugs (10 bugs)

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

Section P - Error correction bugs (49 bugs)

Part 4 - CSS 2 that IE 4 supports

Total bugs = 26 + 3 + 15 + 16 + 1 + 11 + 8 + 6 + 14 + 9 + 5 + 12 + 8 + 10 + 10 + 49 = 203.


Section H - width bugs

width
Bug 1: Elements that overflow their containing block

When an element is too big for its containg block, it should overlap outside the block, but in IE 4 it doesn't, instead causing the block to be enlarged. E.g.:

P {width: 400px;
border: solid;
padding: 0}
DIV {width: 300px;
border: solid}
<DIV>
<P>
Hello
</P>
</DIV>

This also applies to elements that overflow the root element, except with these subsequent elements' content is not extended, but their backgrounds and borders are. For example, an element with width: 200% would cause the content area of subsequent elements to be the normal size, but there would be a large amount of space to their right that would be red. This would only be noticed if a background or border (except left border) was set.

Note that this is significant insofar as padding-right: 0 will not work to suppress this - the space is in addition to padding-right.

Note as well that this bug doesn't apply to elements whose width has been extended via margin-right.

Bug 2: only works on DIV

Width only works on DIV, table elements and replaced elements.

Bug 3: small widths

You should avoid widths smaller than the width of the widest word or replaced element in the block; for example, width: 0, which should result in every word overflowing (and hence being visible) the containing block would instead chop off every word that overflowed the containing block - that is all of them. Typically words do not exceed 30 pixels in wide; the width of replaced elements depends on which you use, but you should avoid setting the block width to less than that of the widest one.

Height
Bug 4: suppresses margin-right

If you make a height declaration on an element, it results in margin-right being ignored.

Bug 5: only works on DIV

Height only works on DIV.

Bug 6: elements that should overflow the bottom of elements instead extend their height

Where an element has an explicitly set height, all content that is taller than it should overflow the block. IE 4 instead causes the element to be increased in size to fill all the content; for example, height: 100px with an element inside it that is taller than that should result in it overflowing the element's bottom, but in IE 4 results in the height being increased.


Section I - Float and clear

Floating inline elements
Bug 1: width

The CSS spec states that width is required on floating elements, and that if it is unspecified, it should be set to 0. IE does not follow this, and instead sets it to 100%.

This will cause problems if you inadvertently omit width when creating drop-caps, so you should always include width (I find 0.4em is the best setting).

This is not, in practice, a serious bug because you are required (by the spec) to always set width on floats anyway.

Bug 2: inline floats that are not the first thing in their line box are moved down to the line beneath

Although the CSS spec states that floats that are not the first thing in their line box should simply result in reflow around the point from which they were displaced; for example, <P>e<SPAN style="float: left; width: 1em">m</SPAN> like</P> would result in 'me like'; IE 4 does not apply this, instead preferring to move the float down to the next line unless it is the first thing in its line box. Thus:

(a) Find the turning points of the function y=x3. <span style="float: right; width: 3em; text-align: right">(20)</SPAN>

would result in the (20) being moved down to the line below instead of being right-aligned within the line box as it should be; whereas:

<span style="float: right; width: 3em; text-align: right">(20)</SPAN>(a) Find the turning points of the function y=x3.

is non-problematic because the float is the first thing in its line box (as, for example, drop caps always will be, so these aren't problematic). This presents a problem insofar as the natural place for the float in the markup is on the right, because this is the logical place for non-CSS supporting browsers, but in IE 4 it won't work unless it is placed in the illogical place on the left.

Bug 3: floating elements that overlap with subsequent block elements

IE 4 has quite serious problems with floating elements that overlap with subsequent block elements, handling in them in a badly buggy way. Rather than merely treating them as overlapping the block element but shortening line boxes, it treats them as actually taking a chunk out of that element. For example:

<P>
<IMG style="float: left">
</P>
<P style="background: red">
Some text in the P element.

Although the effect of the floating image should be to overlap with the block below (provided it is tall enough), but shorten the line boxes within it, in IE 4, the effect is to cause a chunk to be taken out of the block, therefore meaning that backgrounds around the P will be the wrong color. Note that this only has an effect when backgrounds are set (not borders).

There is a demonstration of this in one of RichInStyle.com's bug pages.

Bug 4: text wraparound is only done on one side

IE 4 only supports text wrapping on one side of a float. For example:

<P style="margin-left: 100px">
<IMG style="float: left">
</P>
<P>
This text should flow on both sides of the image - to its left and to its right, but in IE 4 will only flow on the right.

Similarly:

<P style="margin-right: 100px">
<IMG style="float: right">
</P>
<P>
This text should flow on both sides of the image - to its left and to its right, but in IE 4 will only flow on the left.

There is a demonstration of this in one of RichInStyle.com's bug pages.

Bug 5: floating elements within containing blocks that have a background color cause problems

If a floating element is floated within a containing block that has a background color, problems might be caused, the float being given a background that stretches all the way to the left of the page. For example:

<p style="background: red; border: none">
<img hspace=3 src="stars.gif" style="float: left">The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?
</p>

In this example the red background would be placed to the left of the floating image all the way to the left of the canvas in a most unsightly manner.

There is a demonstration of this in one of RichInStyle.com's bug pages.

Bug 6: floats aligned with border edge rather than content edge.

IE incorrectly aligns floated elements with the border edge of their containing block rather than the content edge. For example, <P style="padding-top: 100px; border: solid 10px"><SPAN style="float: left; width: 1em">M</SPAN>e</P>, which should align the top of the M with the top of the line box from which it was displaced; i.e., its baseline should be aligned with that of the e, instead aligns it with the top of the border, which is 110 pixels too high!

There is a demonstration of this in one of RichInStyle.com's bug pages.

Bug 7: backgrounds of margins of floating elements

IE 4 gets the backgrounds of the margins of floating elements wrong - it makes them the color of their containing block, even if they aren't in that containing block. For example:

<P style="background: blue">
<IMG style="float: left">
</P>
<P>
A P element with a top margin

In this case the horizontal space (set by hspace (an HTML attribute, with a default non-zero value) or margin, around the IMG would be blue, even when it is in the (probably) white space between the P elements. This is incorrect because margins are simply transparent, which means that they should be the color of the element underneath - the background of the element from which they started is irrelevant.

There is a demonstration of this in one of RichInStyle.com's bug pages.

All floats
Bug 8: content that overflows floats rendered invisible

Content that overflows floated boxes is rendered invisible. The exhaustive list of cases that this will affect are:

  1. Drop caps overflowing their box (e.g., because their line-height is much less than font-size).
  2. Small left margins on OL/UL causing the marker glyph to be rendered outside of the box.
Floating block elements
Bug 9: Not wrapped

Although the CSS specification states that where a float will overflow its containing block due to another float, the float should be moved below that float, IE fails to follow this, instead allowing the containing block to be overflowed, thus causing a scroll bar as a result of the third of the element's below overflowing the containing block:

<DIV style="float: left; width: 50%">
</DIV>
<DIV style="float: left; width: 50%">
</DIV>
<DIV style="float: left; width: 50%">
</DIV>

To avoid this, you should always use clear to do what the browser should do for you. E.g.:

<DIV style="float: left; width: 50%">
</DIV>
<DIV style="float: left; width: 50%">
</DIV>
<DIV style="float: left; width: 50%; clear: left">
</DIV>
<DIV style="float: left; width: 50%">
</DIV>
etc.

Bug 10: right-floated element followed by non-floated element increases padding to twice the width of the viewport

If you follow a right-floated element with a non-floated element, this wil increase the padding-right of the non-floated element to such an amount as to make the total width of the non-floated element twice that of the viewport. For example:

<div style="float: right; width: 20%">
A right float
</div>
<div style="background: blue">
And some text, which will flow around it in a pleasing way. Isn't that wonderful? And some text, which will flow around it in a pleasing way. Isn't that wonderful? And some text, which will flow around it in a pleasing way. Isn't that wonderful?
</div>

This example would result in the non-floated DIV being given an enormous padding-right. Note that it would only be visible if you give the element a background.

Bug 11: block elements that follow floats that combine to the width of the containing block or nearly that, trigger horrendous bugs unless cleared

Although the code below should result in the P text below the DIV (although the P's block is the top of the float, the float's width is the same as P's, and thus it will appear to be below it), IE will put some of the content next to the float (thus triggering an unsightly scroll bar), and some beneath it. Thus bad in IE 4 is:

<DIV style="float: left; width: 100%">
</DIV>
<P style="/* since the width of the previous element is 100% of the viewport, this element's content must go below the floated div, but it won't */">
P's content here
</P>

Good is:

<DIV style="float: left; width: 100%">
</DIV>
<P style="clear: left">
P's content here
</P>

Bug 12: horizontal rules overlapping with floats shortened instead of overlapped

When horizontal rules overlap with previous floats, instead of overlapping, as would be correct, they are shortened.

Clear
Bug 13: allowed to affect inline content

IE 4 allows clear to affect inline content of elements; for example:

<p style="clear: left; background: red; border: none">
<img src="stars.gif" style="float: left">The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?The text should flow around the image in an attractive manner. Do you see?
</p>

In this example the clear should have no effect unless there is a previous floating element, but in IE 4 it will result in the text being placed below the bottom of the image.

There is a demonstration of this in one of RichInStyle.com's bug pages.

Bug 14: clear on floated elements allowed to affect block elements

Since floated elements are removed from the normal flow, although clear obviously affects the floats themselves, it doesn't affect subsequent block elements. In IE 4 however, if a floated element is cleared it is erroneously allowed to affect subsequent non-floated elements. For example, <DIV style="float: right; width: any"> <DIV style="float: right; clear: right; width: any"></DIV <P>, which should place the top border edge of the non-floated P at the top of the first right-floated P instead puts it at the bottom of the cleared element.

If you don't understand why this is so, see RichInStyle.com's floats document.

Reminder

Width only works on DIV, ergo only use DIV for floats.

Bug 15: initial IE 4 release irrevocably destroys system if clear used

The initial release of IE 4, supplied with many computers will crash the computer completely if clear is used.

Avoid it.


Section J - Display, cursor and print bugs

Cursor
Bug 1: url

Cursor: url() doesn't work.

Bug 2: pointer

Cursor: pointer doesn't work, but cursor: hand does (a pre-CSS2 name for it), so declare SELECTOR {cursor: pointer; cursor: hand} instead. You must declare it in that order, because of IE's bug of not ignoring invalid declarations (pointer is invalid to it), but instead applying the initial value. This won't cause problems with compliant UAs, since these would ignore (i.e., treat as though it wasn't there) the cursor: hand declaration.

Bug 3: auto

Cursor: auto doesn't work. For example, say you put HTML {cursor: default} to set the cursor to the pointer rather than the I bar, but on DIV you want the browser to use its usual cursor for this element (the I bar), so you put DIV {cursor: auto} to allow the browser to determine it itself. In IE 4 this won't happen because it doesn't support cursor: auto.

Most of the effect of this bug is removed, however, by the fact that in its browser style sheet it has the cursor set for the A, INPUT, BUTTON and TEXTAREA elements.

This means that if you specify INPUT {cursor: auto} to override the HTML {cursor: default} statement, it will actually work, although not because of the reason you told it to - IE 4 would apply automatic cursor selection to INPUT anyway, so it would actually use the right cursor (the only way to change the cursor on these 4 elements is to explicitly state a different one - inheritance won't work (note that this is not a bug because it is permissible for UAs to have this in their browser style sheet; however, it is arguably bad practise).

Bug 4: n-resize, ne-resize, nw-resize, w-resize, e-resize, s-resize, se-resize, sw-resize buggy

IE 4 uses the wrong cursor for n-resize, ne-resize, nw-resize, w-resize, e-resize, s-resize, se-resize and sw-resize - it uses a single-headed cursor, whereas in Windows these cursors are double-headed cursors (in addition, se-resize should be the same as nw-resize - it is not in IE 4).

display
Bug 5: display: block doesn't work

Display: block doesn't work.

Bug 6: display: inline doesn't work

Display: inline doesn't work.

Bug 7: display: list-item doesn't work

Display: list-item doesn't work.

page-break-before, page-break-after
Bug 8: left and right treated as always

IE 4 treats the left and right values as always. This is wrong even though IE 4 prints left and right pages the same. For example, <P style="page-break-before: left> <P style="page-break-before: right>, which should result in one or two page breaks before the first element and two or one (the other number from which the previous element caused) simply results as one.

Note that this is non-serious bug because as IE 4 doesn't maintain any difference between left and right pages, it makes little difference.

Bug 9: avoid unsupported

IE 4 does not support the 'avoid' value of page-break-before or page-break-after.

Printed margins
Bug 10: still honored at the top of pages

IE 4 incorrectly uses margin at the top of pages; for example, P {margin-top: 3in} should not give the P a top margin if the P starts on a new page, but in IE 4 it does.


Section K - Positioning

Position
Bug 1: position: absolute only works on DIV and TABLE

Only <DIV> and <TABLE> of block elements can always be absolutely positioned.

Overflow
Bug 2: scroll doesn't always result in a scroll bar

Overflow: scroll, which should always result in a scrollbar (e.g., so that content can be dynamically removed and added without causing reflow), only results in one when overflow occurs in IE.

Bug 3: overflow-handling behavior only triggered for content that overflows the bottom of its containing block

IE only honors overflow for content that overflows the bottom of element. For example, height: 10px; overflow: whatever would trigger the overflow-handling behavior if the content overflowed the bottom (note that content that overflows the top is always treated as overflow: visible)of the block as a result of that height declaration, but all other overflow would be treated as visible.

Information: auto's treatment

IE treats overflow: auto as overflow: scroll when the element overflows its containing block, but overflow: visible otherwise (as is its prerogative).

Clip
Bug 4: not supported

IE does not support clip.

Visibility
Bug 5: hiden suppresses element and all descendants

The visibility property should not cause suppression of the element and all its descendants; for example, <P style="visibility: hidden">Some hidden text <SPAN style="visibility: visible">and some visible text</SPAN></P>, should result in the visibility: visible text being visible. However, in IE visibility: hidden erroneously causes the element and all its descendants to be suppressed and this example would cause a totally hidden element in IE.


Section L - Form bugs

Inheritance

Form controls do not inherit style, but have the OS-default styles applied to them (typically font-size: 10pt (or thereabouts); font-family: serif; color: black; background: white, but it depends on the OS' settings). This is not a bug, since this is validly includable in a browser style sheet (necessarily via UI fonts and colors).

Superior to all browsers is the fact that this can be overridden.

Note that padding, margin and border do work on form elements, even though they do not work on other inline elements.

Bug 1: Height and width unsupported on INPUT type="radio" and type="checkbox"

IE 4 does not support height or width on INPUT type="radio" or type="checkbox".

Bug 2: Font properties not supported on OPTION

Font properties can only be applied to <SELECT>, not to <OPTION>.

Bug 3: Background and color

Radio buttons, check boxes and upload buttons (but not the text box) on INPUT type="file" can't have backgrounds or color.

Bug 4: background images

IE 4 does not support background images on SELECT or OPTION elements.

Bug 5: line-height not supported on OPTION

Although IE 4 applies line-height to BUTTON, SELECT, INPUT type="reset", type="submit" and type="button", it does not apply it to OPTION.

Bug 6: line-height and padding destroyed on INPUT type="text" and type="password"

IE 4 destroys line-height and padding on INPUT type="text" and type="password" by applying it but not increasing the height of the box to compensate, thereby hiding any initial (via value="") content of these controls.

Bug 7: text-decoration unsupported on SELECT, OPTION and INPUT type="image"

IE 4 does not not support text-decoration on SELECT, OPTION or INPUT type="image" (i.e., on the alt text of INPUT type="image").

Bug 8: white-space unsupported on TEXTAREA

IE 4 does not support white-space on TEXTAREA, irrevocably applying it as a preformatted element.

Bug 9: padding not supported on SELECT or OPTION

IE 4 does not support padding on SELECT or OPTION.

Bug 10: margin not supported on OPTION

IE 4 does not support margin on OPTION.

Bug 11: border not supported on INPUT type="radio" or type="checkbox"

IE 4 does not support borders on INPUT type="radio" or type="checkbox".

Bug 12: border rendered as transparent on INPUT type="image"

IE 4 applies borders on INPUT type="image", but it always applies them as transparent.


Section M - HR bugs

Bug 1: margin-right set on its own

Where margin-right is set on a horizontal rule, but width is not, margin-right is applied, but width is not altered to compensate, thus meaning that the containing block will be overflowed, probably resulting in a scroll bar being added to the document. This means that you should not set margin-right on its own.

Bug 2: width set on its own

When width is set on a horizontal rule, IE centers it.

Bug 3: margin-left set on its own

When margin-left is set on its own, width is not altered to compensate, thus meaning that the rules containing block will be overflowed, probably resulting in a scroll bar and the rule being pushed off the screen.

Bug 4: both margin-left or margin-right and width set

When both margin-left/margin-right and width are set on a horizontal rule, they are applied subject to the normal margin bugs, but since IE does not adjust values to fit the viewport on HR, a scroll bar will result (since it is highly unlikely that BODY's width, which is what HR should relate to, will be exactly that of the viewport).

What does it all mean?

All this means that you should not apply box model properties to HR (padding doesn't work at all, so this might be an alternative to exclude IE). [At a pinch you could try: HR {width: desired width - BODY's margin-right + BODY's paddding-right; margin-right: 100% - (BODY's margin-left + BODY's padding-left) - desired width}
E.g., given BODY {margin-left: 10%; margin-right: 5%;} then HR {width: 50%; margin-right: 40%} would work to get the width of 40%, and wouldn't conflict with other browsers]

However, the best solution if you only need to adjust a few HRs, you should just use the width attribute in the markup.

Bug 5: Height in %

Height in % doesn't work on HR.

Bug 6: color applied as a border and background color

IE 4 draws HR as a border around a transparent box. This means that you should be able to change the border color and background color. It ignores both of these properties on HR and only applies color to HR, which causes the HR to be set to a solid color.

Bug 7: border properties

Border properties don't work on HR

Bug 8: padding

Padding doesn't work on HR


Section N - Table bugs

Bug 1: borders on captions

IE does not alter the size of captions to apply borders, and as a result, borders that are more than 3 px thick will cause overlapping. You can get round this by applying as much padding as border to the CAPTION.

Bug 2: height, width, position and margins not honored on CAPTION

IE ignores height, width, position and margins on CAPTION.

Bug 3: inheritance

Of the font properties, the only one that IE 4 inherits into TABLEs is font-family, applying font-size: default value; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none unless you set different values. [Note inheritance works from TABLE into TD/TH/TR, just not from BODY into TABLE]

Bug 4: inheritance

IE incorrectly fails to apply the parent element's color to TABLEs, instead applying that of the BODY. As a result, given, e.g., DIV {background: red; color: green} BODY {background: green; color: red}, the TABLE would be green (BODY's) on green =invisible.

Bug 5: padding not applied to tables or table rows, but instead inherited therefrom

IE 4 does not apply padding to TABLEs, table row groups, or table rows, but instead inherits the padding to the cells; for example, TABLE {padding: 10px} would inherit that padding to the cells.

Bug 6: table rows and cells can't be positioned

IE 4 does not allow table rows, row groups or cells to be positioned.

Bug 7: properties 'inherited' from columns

IE 4 incorrectly allows inheritable properties to inherit from columns. For example, COL style="color: red" would make the table cells red, which is incorrect because the only properties that should have an effect on columns are background, border, visibility and width. Similarly, COL style="visibility: hidden" is allowed to hide the column by reason of its inheritance whereas to hide the column actually requires COL style="visibility: colapse".

Bug 8: unclosed P prior to table causes the table to be considered as part of the P

If you fail to close a P element before a table the table will be treated as part of the P element, which is incorrect since P cannot contain other block elements (such as TABLE), and therefore the start of the TABLE implies the end of the P. Thus <P style="border: solid; background: red; margin-right: 50%"><TABLE> will cause the TABLE to be inside the P. As a result, you should close P elements before tables, and must close them when the P has a lot of inheritable styles.

Bug 9: text-align applied to TABLEs

IE 4 applies text-align to TABLEs, which is incorrect since they are block elements, whereas text-align only applies to inline elements.

Bug 10: text-align not inherited into table cells

IE 4 fails to inherit text-indent into table cells instead applying text-align: left.


Section O - List item bugs

List styling
Bug 1: marker not taken into account for finding height of the line box

IE 4 does not take into account the marker box for the purposes of finding the height of the line box; for example, LI {line-height: 100px; background: red} with a SPAN.insideLI {line-height: 10px} should make the line box 100 pixels high because the line-height of the list marker is 100 pixels, but in IE 4 will give 10 pixels high. Again, this is unlikely to cause any problem.

Bug 2: backgrounds color too much of list items

Although backgrounds should only color the space behind the text (and not the list marker), IE 4 colors part of the space to the left of the text as well. E.g., LI {background: red}, which shouldn't color anything to the left of the text content, does, coloring part of the list marker as well.

Bug 3: borders cover too much of the box

Borders on list items cover too much of the box - they overlap with ordered markers (e.g., 1, 2, 3) and cover too much of unordered ones. Note that although annoying, this is a non-catastrophic bug.

Bug 4: text-indent moves list marker

Text-indent moves the list marker as well as the content, whereas it should just move the content.

Bug 5: text-align moves list marker

Text-align moves the list marker as well as the content, whereas it should just move the content.

Bug 6: list items overlap wrongly with floats

When list items overlap with floats, they behave wrongly - the border edge of the list item is placed next to the right of the float instead of next to the left of the float.

List style positions
Bug 7: unsupported

IE 4 doesn't support list style positions.

List style types
Bug 8: '.' placed after ordered list marker glyphs

Internet Explorer 4 places a '.' after markers on decimal, lower-alpha, upper-alpha, lower-roman, upper-roman (1., 2., 3., rather than 1, 2, 3), which is technically incorrect.

List style images
Bug 9: all but small images destroy when line-height is set to a value other than normal

If you use any other than small images and set line-height to a value other than normal (even <number> is problematic), Internet Explorer 4 will destroy the list item. This is because rather than placing the right edge of the list marker (say) 10 pixels from the left of the content it is marking, it places the left edges relative to the left of the content - regardless of the size the image. As a result, you should use list images that are an absolute maximum of 30 pixels wide.

List-style
Bug 10: none doesn't work

Although the list-style shorthand resets all unset values to their initial value, in IE 4 it doesn't, and list-style-image: url(listimage.gif); list-style: decimal, which should apply decimal (equally so when a list style image is inherited), not the image, applies the image. This bug is avoidable by declaring list-style-image: none (adding none to the list-style shorthand won't work).


Part 2 - (In)Validation problems

Section P - error correction problems

Some people might think that these are irrelevant, and that it is pointless pedantry to list them.

They would be wrong.

The habit ominpresent amongst browser makers of permitting invalid style is a dangerous one that causes many problems. For example, say you have @import url("wrong.css);. This would work in IE, and as a result the author would have no idea that anything was wrong.

Unfortunately, when they (or worse, someone else) came to look at the page in a compliant browser, it would not look correct. In addition, other problems introduced by the habit of browers of not ignoring invalid CSS include the encouragement of sloppy or invalid design. As an example, I have seen many people using SPAN for styles that are only valid on block elements. Because this works in many browsers, they are not encouraged to produce valid CSS, and as a result their site will suffer.

  1. Border-style: solid thin is rendered as if it were border-style: solid none none none, but this isn't valid CSS.
  2. Style is applied when element_name is enclosed in < and >, which isn't legal CSS.
  3. Width is applied to inline elements, transforming them to floating block elements.
  4. Height is illegally and buggily applied to inline elements.
  5. The font shorthand works even when both of size and family have not been specified.
  6. IE 4 allows invalid line heights in the font shorthand; for example, no space after the line height or a space before or after the /.
  7. IE 4 permits (ignoring) carriage returns and line feeds inside strings in the string macro when it forms part of the URI token, but this isn't allowed.
  8. It permits the end (but not beginning) quote to be omitted from the URI token.
  9. Style sheets are imported that do not precede all blocks, which is prohibited by the CSS spec.
  10. P/* comment */ .class is parsed as P.class, even though this is wrong since spaces aren't ignored after comments.
  11. Inline style contained in curly brackets is rendered
  12. Margins separated by commas are rendered: e.g., margin: 12pt, 12pt, 12pt, 12pt;
  13. Vertical-align is (buggily) applied to block elements, whereas it only applies to inline elements by the spec.
  14. White space such as a line feed is incorrectly ignored at the end of font-family declarations - e.g., font-family: "Courier New
    " works but shouldn't.
  15. It tolerates invalid border declarations; for example, border: solid thick thin applies a solid thin border and solid red groove, red medium groove.
  16. Fonts containing white space without quotes are incorrectly parsed as such, whereas the CSS spec states that the white space should be removed - e.g., font-family: Times New Roman should become font-family: TimesNewRoman.
  17. It incorrectly allows non-integer values on the decimal rgb format
  18. It destroys future colors - color: red; color: 3dbackground is treated as color: [no declaration].
  19. It doesn't ignore shorthand declarations where part of the value is invalid
  20. If the unit is omitted from DIMENSION tokens, IE 4 implies px, but this is invalid and the declaration should be ignored.
  21. It incorrectly allows more than 1 decimal place on the % rgb format
  22. Colors without the # sign are applied.
  23. SELECTOR {property: } is parsed as SELECTOR {property: initial-value}, which is not correct (the declaration should be IGNOREd).
  24. Values in quotes are illegal, but IE 4 applies them (e.g., font-size: "12pt").
  25. If more than four margin values are provided, IE 4 applies the first four.
  26. It fails to treat the first instance of </ as terminating <STYLE>.
  27. It allows IDs to contain character references, but this isn't valid.
  28. It illegally allows tokens to start with very many invalid characters; for example, #1 and #-id are both invalid, but IE 4 will accept them.
  29. If the closing } is omitted on a ruleset, the style is applied provided the ';' is included.
  30. If a selector is omitted, it implies the root. Thus {color: red} is equivalent to HTML {color: red}.
  31. IE 4's element matching is deeply shoddy when an id or class is specified. If the element specified with the selector is unknown to it, it ignores it entirely (i.e., the type selector). For example, hello.class would be parsed as .class, although p.class would work fine. Equally for hello#class.
  32. It applies rulesets that contain invalid combinators as part of one of their selectors by applying the ruleset only to the last selector, rather than ignoring it entirely as it should. E.g., DIV & P, .eight would be applied to .eight, but .eight, DIV & P would result in .eight being ignored.
  33. IE 4 destroys pages that don't include at least one closing comment tag for all the open ones (e.g., --> for all the <--). This is incorrect because it shouldn't treat comments in the style element as such; however, it isn't serious because it's a stupid thing to do anyway.
  34. It permits comments inside the uri token, but comments aren't allowed inside tokens, only between them.
  35. It has destroyed any future vertical-align values by not correctly ignoring them - vertical-align: super; vertical-align: newvalue should apply super in IE 4, but doesn't simply resulting in baseline.
  36. It disregards the case of proprietary font names (e.g., aRial).
  37. It allows Times to match Times New Roman
  38. If % is used on height without the ancestor having an explicit height, the % is related to the height of the viewport, but it should be treated as auto.
  39. It will ignore any number of characters between a property and its colon; for example, color 4536487587: red would apply color: red! Note this only applies where there is an space between the property name and the invalid characters.
  40. It treats the media attribute as case-insensitive
  41. It doesn't ignore text-decoration declarations that contain an invalid value provided they contain at least one value; for example, text-decoration: underline cheese would apply text-decoration: underline, but should be ignored as invalid.
  42. It fails to truncate the media attribute - whereas media="screen fhdfk dfjkd hf" should be treated as screen, IE doesn't bother. Compare this with Opera, which does correctly truncate it.
  43. IE 4 applies text-align to horizontal rules, but it should have no effect on them - the correct way to center (for instance) horizontal rules is with margin-left: auto; margin-right: auto, and a width value < 100%.
  44. It allows non-integer values on z-index (rounding down).
  45. It allows background position keywords to be mixed with lengths, but this isn't valid
  46. It will have problems with future cursor values because it does not ignore them; for example, cursor: wait; cursor: busy, which should result in cursor: busy being ignored and thus reversion to cursor: wait, in IE 4 results in the inherited cursor (or browser cursor in the case of BUTTON, INPUT, A and TEXTAREA).
  47. It applies % on top when the containing block doesn't have an explicitly set height, but this should be ignored.
  48. It allows spaces between numbers and the length; for example, it allows 5 em, but this isn't valid.
  49. It allows = to be used for style assignment (i.e., instead of :).

CSS 2 that IE 4 supports

IE 4 introduced the border-left-color, border-right-color, border-bottom-style, etc. syntax that now form part of CSS 2, and as such they all work in IE 4.

IE 4 also supports cursor (except as noted above), user interface based colors (e.g., color: menutext) and user interface based fonts (except as noted).

IE 4 supports the page-break-before and page-break-after properties.

It also supports (albeit buggily; see part 1) the :hover pseudo-class.