|
|||||||
|
|||||||
|
Section A - Bugs relating to embedding, linking and parsing style sheets (26 bugs)
Section B - Bugs with units (3 bugs)
Section C - Font bugs (15 bugs)
Section D - Text bugs (16 bugs)
Section E - Color and background bugs (1 bug)
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)
Section L - Form bugs (12 bugs)
Section N - Table bugs (10 bugs)
Section O - List item bugs (10 bugs)
Section P - Error correction bugs (49 bugs)
Total bugs = 26 + 3 + 15 + 16 + 1 + 11 + 8 + 6 + 14 + 9 + 5 + 12 + 8 + 10 + 10 + 49 = 203.
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.
Width only works on DIV, table elements and replaced elements.
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.
margin-rightIf you make a height declaration on an element, it results in margin-right being ignored.
Height only works on DIV.
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.
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.
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.
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.
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.
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.
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.
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.
Content that overflows floated boxes is rendered invisible. The exhaustive list of cases that this will affect are:
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.
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.
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>
When horizontal rules overlap with previous floats, instead of overlapping, as would be correct, they are shortened.
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.
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.
Width only works on DIV, ergo only use DIV for floats.
The initial release of IE 4, supplied with many computers will crash the computer completely if clear is used.
Avoid it.
Cursor: url() doesn't work.
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.
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).
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: block doesn't work.
Display: inline doesn't work.
Display: list-item doesn't work.
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.
IE 4 does not support the 'avoid' value of page-break-before or page-break-after.
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.
Only <DIV> and <TABLE> of block elements can always be
absolutely positioned.
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.
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.
IE treats overflow: auto as overflow: scroll when the element overflows its containing block, but overflow: visible otherwise (as is its prerogative).
IE does not support clip.
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.
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.
IE 4 does not support height or width on INPUT type="radio" or type="checkbox".
Font properties can only be applied to <SELECT>, not to
<OPTION>.
Radio buttons, check boxes and upload buttons (but not the text box) on INPUT type="file" can't have backgrounds or color.
IE 4 does not support background images on SELECT or OPTION elements.
Although IE 4 applies line-height to BUTTON, SELECT, INPUT type="reset", type="submit" and type="button", it does not apply it to OPTION.
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.
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").
IE 4 does not support white-space on TEXTAREA, irrevocably applying it as a preformatted element.
IE 4 does not support padding on SELECT or OPTION.
IE 4 does not support margin on OPTION.
IE 4 does not support borders on INPUT type="radio" or type="checkbox".
IE 4 applies borders on INPUT type="image", but it always applies them as transparent.
margin-right set on its ownWhere 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.
When width is set on a horizontal rule, IE centers it.
margin-left set on its ownWhen 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.
margin-left or margin-right and width setWhen 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).
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.
Height in % doesn't work on HR.
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.
Border properties don't work on HR
Padding doesn't work on HR
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.
IE ignores height, width, position and margins on CAPTION.
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]
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.
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.
IE 4 does not allow table rows, row groups or cells to be positioned.
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".
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.
IE 4 applies text-align to TABLEs, which is incorrect since they are block elements, whereas text-align only applies to inline elements.
IE 4 fails to inherit text-indent into table cells instead applying text-align: left.
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.
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.
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.
Text-indent moves the list marker as well as the content, whereas it should just move the content.
Text-align moves the list marker as well as the content, whereas it should just move the content.
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.
IE 4 doesn't support list style positions.
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.
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.
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).
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.
{color:
red} is equivalent to HTML {color: red}.margin-left: auto; margin-right:
auto, and a width value < 100%.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.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.