|
|||||||
|
|||||||
|
Section A - Bugs relating to the attachment of styles to pages (5 bugs)
Section B - Bugs relating to the application of styles to elements (10/12 bugs)
Section C - Bugs relating to key concepts (5/3 bugs)
Section D - Bugs with units (1 bug)
Section E - Font bugs (13 bugs)
Section F - Text bugs (15/13 bugs)
Section I - Width and height bugs (4 bugs)
Section J - Float and clear bugs (7/6 bugs)
Section K - Display, cursor and printing bugs (7 bugs)
Section L - Positioning bugs (4 bugs)
Section M - Form bugs (10 bugs)
Section O - Table bugs (5/4 bugs)
Section P - List item bugs (8 bugs)
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.
When an element is too big for its containg block, it should overlap outside the block, but in IE 5 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.
Where an element has an explicitly set height, all content that is taller than it should overflow the block. IE 5 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 5 results in the height being increased.
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 5 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 5 it won't work unless it is placed in the illogical place on the left.
IE 5 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 5 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 5 will
only flow on the left.
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.
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 5 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.
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 5 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.
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 5 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 5 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 practice).
IE 5 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 5).
Display: list-item doesn't work.
IE 5 treats the left and right values as always. This is wrong even though IE 5 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 5 doesn't maintain any difference between left and right pages, it makes little difference.
IE 5 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 5 it does.
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.
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 5 does not support background images on SELECT or OPTION elements.
Although IE 5 applies line-height to BUTTON, SELECT, INPUT type="reset", type="submit" and type="button", it does not apply it to OPTION.
IE 5 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 5 does not not support text-decoration on SELECT, OPTION or INPUT type="image" (i.e., on the alt text of INPUT type="image").
IE 5 does not support white-space on TEXTAREA, irrevocably applying it as a preformatted element.
IE 5 does not support padding on SELECT or OPTION.
IE 5 does not support margin on OPTION.
IE 5 does not support borders on INPUT type="radio" or type="checkbox".
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; 100% - (BODY's
margin-right: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 5 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 ignores height, width, position and margins on CAPTION.
IE incorrectly fails to inherit any styles from the parent element except font-family, instead inheriting those 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. Similarly, DIV {font-family: 16px sans-serif} would inherit the sans-serif but not the 16 pixels.
IE 5 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 5 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.
Where content overflows the border edge table cells (as a result of a negative margin), it will be rendered invisible. For example, say you have H1 {margin-left: -5%} in a table cell. This would cause all of the H1 that overflowed the table cell to be rendered invisible.
IE 5 applies table-layout: fixed even when the table hasn't been explicitly assigned a width. This is incorrect.
If as a result of table-layout: fixed, content overflows table cells, IE 5, instead of allowing it to overflow, will truncate it, thereby making it invisible.
IE 5's border-collapse implementation is badly broken. To see this demonstrated, you should click here.
IE 5 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 5 will give 10 pixels high. Again, this is unlikely to cause any problem.
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 (e.g., DIV {float: left; width: 50%} followed by an uncleared LI), the marker is suppressed.
When you set font-size very large (> 100px), because IE 5 measures the distance from the left of the marker to the left of the principal box, it will overlap with the principal box.
List-style-position: inline is glitchy - it should result in the marker being placed as the first item of content in the principal block, much as the 'L' at the start of this sentence is the first item of content in its principal block, but in IE 5 it will straddle the two. This is annoying but not catastrophic.
It also means that backgrounds will cause problems.
Internet Explorer 5 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 5 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 5 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.
margin-left: auto; margin-right:
auto, and a width value < 100%.Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.