|
|||||||
|
|||||||
|
Section A - Bugs relating to embedding, linking and parsing style sheets (36 bugs).
Section B - Bugs with units (2 bugs).
Section E - Color and background bugs (25 bugs).
Section F - Margin bugs (13 bugs)
Section G - Other bugs - unsupported properties (25 bugs)
Section H - Form bugs (5 bugs)
Section I - Table bugs (12 bugs)
Section J - List item bugs (2 bugs)
Section K - Horizontal rule bugs (1 bug)
Total bugs = 36 + 2 + 25 + 14 + 25 + 13 + 25 + 5 + 12 + 2 + 1 + 37 = 197.
IE 3 doesn't support colors in either of the rgb formats. This could make pages unreadable if a foreground and background color are codependent. However, it is easy to change them. For example, color: rgb(255, 0, 125) becomes color: #FF007D.
IE 3 doesn't parse color keywords correctly - it correctly parses (i.e., ignores) color declarations containing keywords that are unknown to it that are unique in their ruleset, but where there is more than one color (background works fine) declaration in a ruleset and one is inherit or a user interface color (such as buttonhighlight), the wrong color will be applied. For example:
P {color: red;
color: inherit;
}
Applies #00e000, but:
P {color: inherit;
}
is correctly ignored.
IE 3 does not support color on the IMG element (i.e., to specify the color of alt text).
IE 3 doesn't support any background property on LINKed style sheets on what it treats as block elements = HTML, BODY, TABLE, FORM, TR, TD or TH.
If you've followed my advice for older browsers (i.e., adding bgcolor, etc., to BODY), this won't be a problem, but if you haven't, there are three ways around this difficulty: 1. use an inline stylesheet just for background, 2. don't use a background color, 3. use bgcolor, background, etc. on the BODY tag.
IE 3 treats all text elements (such as P, DIV and ADDRESS) as inline. This means that only the space behind the text is colored in if you specify a background color or image different to BODY's on these elements. The leading will not be colored in. There is a way around this, however, and that is to enclose the elements in a TABLE (without any rows or cells) (though not with external style sheets).
This means that I strongly recommend that you do not specify backgrounds on these elements in IE 3.
By default, backgrounds should be transparent. This means that an element has the background-color of its parent. In IE 3, however, this doesn't apply, and all elements get BODY's background-color, unless the contrary is stated.
<STYLE>
P {background: red}
</STYLE>
<P>
This is <em>emphasized</em>
</p>
In this example, the EMphasized text should have a red background, but in IE 3 it will have BODY's background color. We fix it by adding contextual selectors for every element that could be inside an element with a background different to that of BODY's, or by enclosing them in rowless and cell-less TABLEs (note that this won't work in LINKed style sheets - see Bug 7); the only sensible option for images.
P, P EM, P SPAN, P STRONG {background: red} /* Etc. */
IE 3 does not support background images in LINKed style sheets at all.
You can't give IMG a background different to that of BODY (i.e., for alt text purposes).
Background: none is not supported.
In the css specification, both background: url(back.jpg) and background: url("back.jpg") are legal syntax. IE 3 only supports the first option. It is quite simple to remove the quotes, however (and potentially useful to hide backgrounds from IE 3).
If backgrounds are linked via an absolute url (e.g., http://www.whatever.com/whatever.jpg), IE 3 will not read the image but instead will launch any program that the image type is asssociated with and display it there.
IE 3 does not animate animated backgrounds.
IE 3 does not support lengths on background positions.
If you set a background position in either direction of 0 (but not 0px or 0pt or whatever), it will override any background-color that has been set and apply black.
When a positive offset is set in either direction for background position, then background repeats of repeat are only drawn down and right, repeat-x only to the right, repeat-y only down, etc. As a result, you should not specify a positive background position in the direction of the background repeat - e.g., no positive x-offset with repeat-x, no positive y-offset with repeat-y, and no positive x or y offset with repeat.
IE 3 incorrectly interprets % relative to the height of the currently visible width and height of BODY rather than relative to the viewport when background attachment is set to scroll. This means, for example, if the document only fills half the page, if it has big margins, etc., then it will look stupid, and generally it gets background positions badly wrong.
When you omit one background position, the other should be set to 50% or center, but IE 3 doesn't follow this, and instead applies the same background position as the omitted one, e.g., background: top is applied as background: top left, instead of background: top center as it should be.
If you specify a background position, you must specify both vertical and a horizontal position, even if they are 0, and the background attachment must be set to fixed. In addition, you must not use positive background position with a background repeat of repeat, you must not specify a horizontal offset > 0 with repeat-x and you must not specify a vertical offset > 0 with repeat-y. In addition, since IE 3 does not support lengths, specifying a length as 0, will make the background black!.
BODY {background: url(back.jpg) repeat-x 50% 0%}
/* WRONG - fixed is missing; AND the offset > 0 */
BODY {background: url(back.jpg) fixed 80% }
/* WRONG - you MUST NOT use offsets > 0 with repeat, AND the vertical position has not been
specified */
BODY {background: red url(back.jpg) fixed 0 60% no-repeat}
/* WRONG - 0 should be 0pt (or 0em or whatever) */
Since IE 3 only treats a very few elements as block, only these can have background-position applied to them. Thus for any of the others, enclose them in a TABLE. However, since IE 3 doesn't support background attachment = fixed on elements other than scroll except on HTML/BODY, this is effectively useless (since b-position is broken otherwise).
The fixed background attachment only works on HTML and BODY.
IE 3 only support background repeats on BODY, HTML, TD and TH.
IE 3 does not support this, but it does support it via the background shorthand.
IE 3 does not support this, but it does support it via the background shorthand.
IE 3 does not support this, but it does support it via the background shorthand.
IE 3 does not support this, but it does support it via the background shorthand.
IE 3 does not support this, but it does support it via the background shorthand.
P {background-color: black;
color: white}
At present, IE 3 users would be entirely unable to read the page with this style.
P {background: black;
color: white}
But now they can!
Margin-top only works on inline elements where they are the first bit of content in their containing block (e.g., <P> <SPAN style="margin-top: 10px">H</SPAN>).
According to the CSS specification, margin properties are not inherited. If they were, if you set BODY {margin-top: 2in}, then all the elements inside BODY would also have a top margin of 2 inches (equally for any other block element such as OL). Clearly this would be ridiculous. However, this is just what Internet Explorer 3 does.
To make matters worse, although it inherits values applied to BODY, it doesn't apply them to BODY itself, making margin-top worse than useless on BODY.
However, it is easy to overcome the problem:
BODY {margin-top: 1in}
This becomes:
BODY {} /* Do not under any circumstances put margin-top: 0, because this will inherit - see above */
Next, note that if you apply margin-top to an element that has a default non-zero margin-top, it actually increases the margin.
For example, P {margin-top: 0} is actually interpreted as P {margin-top: 22pt}. You would think therefore, that all you need to do is take 22pt away from your margin-top value for P. However, this is not the case: although this would work between adjacent P's, it would not work between a DIV and a P, because IE 3 applies a smaller margin between DIV and P (i.e., some of P's margin is actually padding, which can't be changed in IE 3), resulting in overlapping. This is not a problem if you use DIV purely to indicate divisions (i.e. rather than as a P-substitute with smaller margins), and never use ADDRESS, and never use lists (:-(), but in reality, this means that margin-top must be removed from all of the following elements:
Because of inheritance, you cannot apply margin-top to DIV if DIV contains any of these elements.
% are incorrectly calculated relative to twice the viewport height on margin-top, rather than relative to the width of the containing block as they should be.
IE 3 ignores margin-bottom. This is not as bad as it might seem, because according to the CSS specification, where two vertical margins meet, the combined margin is the larger of the two, NOT the sum of them, meaning that in most circumstances it will be unnoticeable.
Margin-right does't work on inline elements.
Margin-left only works on inline elements where they are the first bit of content in their containing block.
In IE 3.0 (which is used by about 0.5% of all web users), though not 3.01, 3.02 and 3.03, all margin-left and margin-right declarations are interpreted relative to the left (or right with margin-right) of the viewport rather than the parent element's left (or right) margin. Note that this bug doesn't apply to content within tables - for these the margins are
BODY {margin-left: 12pt}
H1 {margin-left: -5pt}
This should result in H1's with margins 7pt from the left of the page. However, in IE3 3.0, it pushes 5pt of H1 into the left margin, making the headings unreadable.
There is a relatively simple solution here, namely to remove all margin-left declarations except on BODY, or to have separate style sheets for 3.0 and 3.01, 3.02 and 3.03 (i.e., using RichInStyle.com's javascript).
Auto margins are interpreted as 0, which causes seriously problems, as explained above.
% are incorrectly calculated relative to the element's width rather than to the containing block's width on margin-left and margin-right.
The other problem with IE 3 is that when you specify margin-left on BLOCKQUOTE, OL and UL, it interprets the amount of space that you specify as additional to the default. Equally with BLOCKQUOTE and margin-right.
IE 3 applies the first specified margin shorthand value to all four sides (except for the bottom - it doesn't support bottom margins); for example, margin: 10px 20px 30px 40px would simply be applied as margin: 10px.
You can't give FORM a background-image unless you enclose it in a TABLE and apply it to that.
Styles don't work on form elements except for backgrounds as stated below.
Background is applied to form controls as a border-top-color and border-bottom - about 1px high.
This doesn't apply to input buttons, which are correctly treated, and to OPTIONs, on which backgrounds are ignored.
IE 3 applies backgrounds on SELECT as a 2px wide block to the right of the SELECT. This is a bug, but essentially a trivial one.
If you apply text-align to TEXTAREA, it is applied as affecting the containing block. For example, <P><TEXTAREA atyle="text-align: right> wouldn't move the contents of the TEXTAREA, but instead would cause the whole P element to be right-aligned.
Style can't be applied to, and won't inherit from, TABLE and TR in LINKed style sheets, though it will in inline and embedded style sheets. This is true of ALL style. Thus the workaround is to apply them to TD and TH.
You can't give TR a background.
Into, and after, an HTML <TABLE>, the following styles do not inherit if specified in a LINKed style sheet.:
This means that after and inside every TABLE, color and line-height will be lost. This bug fortunately is very easy to fix (especially since you don't declare line-height on BODY in IE3, so that won't cause a problem). Note that it is a serious bug, because if the background-color is black, the color: will be as well making the page invisible. Simply declare color specifically on all elements that are BODY's children. Thus BODY {color: red} becomes H1, H2, H3, H4, H5, H6, P, DIV, ADDRESS, DIV, TD, TH, OL, DL, UL, LI, DD, DT, ADDRESS, PRE, BODY, BLOCKQUOTE, FORM {color: red}. It is of the utmost importance that you do this if using TABLE in IE 3.
IE 3 applies text-align to the TABLE as a whole, which is incorrect since TABLE is a block element and text-align only affects inline content.
If a P element is not explicitly closed by a /P tag before a table, that P's styles will inherit into the table. In practice this means color and the font properties. To workaround this, you can specify the color and font properties on tables or simply close your tables explicitly.
IE 3 applies table backgrounds to captions, but this is wrong since captions are above and outside of the table and therefore should not be backgrounded by it.
IE 3 applies margins to table cells as horizontal padding. It does not apply vertical margins; however, it does inherit them. Correct would be to ignore them entirely.
IE 3 does not apply margins to captions
IE 3 does not apply horizontal margins to tables.
If you fail to close a element in a table, it will inherit the margin, relative to the edge of the table, to any subsequent inline content or horizontal rules, but there the margin will be relative to the canvas. For example:
<TABLE> <TR> <TD> <P> </TABLE> <HR>
In this example the left of the horizontal rule would be at the left of the canvas in 3.0 (but not subsequent versions - in subsequent 3.0x versions the problem only occurs when you set a non-zero margin, because this will be inherited - in 3.0, margin: 0 is relative to the left of the canvas, but in 3.0x it is (correctly) relative to the left of the BODY, so would need a non-zero margin to have any effect) because the margin of the P element relative to the edge of the table would be inherited to the HR element. Similarly:
<TABLE> <TR> <TD> <P> </TABLE> This will be at the left of the canvas
Remedies include following the table with a block non-horizontal-rule element:
<TABLE> <TR> <TD> <P> </TABLE> <P>
Or explicitly closing the TD (not the TR) element:
<TABLE> <TR> <TD> <P> </TD> </TABLE>
Or explicitly closing the P element:
<TABLE> <TR> <TD> <P> </P> </TABLE>
Or including a TD element without an unclosed P element:
<TABLE> <TR> <TD> <P> </P> </TD> </TABLE>
Text-align doesn't work on captions in IE 3.
IE 3 inherits the BODY's margins (not the value, but a fraction thereof) to table cells, although it only does so when the table or one of its ancestors has a width set. To avoid this, you should always specify TD, TH {margin: 0} - this is meaningless for other browsers, but essential to avoid problems in IE 3.
IE 3 applies LI's background to list markers, but this is incorrect.
IE 3 allows text-align to move the marker glyphs of list items, but this is incorrect since they are not part of the principal block and therefore text-align doesn't affect them.
If you apply a background to horizontal rules, it will be applied to the rule and its unsightly - a most unsightly effect.
Em and ex are applied as pt, bizarrely.
{color: red} is equivalent to * {color: red}Since IE 3 doesn't support COLGROUP, COL, ABBR, Q, ACRONYM, etc., (and the rest of HTML 4) you can't apply styles to these elements.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.