| |||||||
| |||||||
|
This page covers IE 5 and 5.5 There is very little difference between v5 and 5.5, the main difference being :first-line and :first-letter support (and accompanying bugs).
Bugs present only in v5 have a big 5. Those only in 5.5 have a big 55. In the bug summaries below, IE 5 is listed first where they differ.
These have sorted into categories. This should make it easy for to you find whether the propertythat you want to use works.
While it should be easily apparent what area you are using, and therefore which section youshould read, everyone uses Sections A through D, so therefore everyoneshould read these sections.
Section A - Bugs relating to the attachment of styles topages (5 bugs)
Section B - Bugs relating to the application of styles toelements (10/12 bugs)
Section C - Bugs relating to key concepts (5/3bugs)
Section D - Bugs with units (1 bug)
Section E - Font bugs (13 bugs)
Section F - Text bugs (15/13 bugs)
Section G - Margin and padding bugs (7/4bugs)
Section H - Border bugs (7/6 bugs)
Section I - Width and height bugs (4 bugs)
Section J - Float and clear bugs (7/6 bugs)
Section K - Display, cursor and printing bugs (7bugs)
Section L - Positioning bugs (4 bugs)
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.
Internet Explorer 5 won't allow you to link to style sheets via http-equiv LINK. This is anon-serious bug because it is madness to link to style sheets in this way anyway.
Although preferred style sheets (i.e., those specified using the title attribute) are mutuallyexclusive within titles, and therefore all except the last one should be ignored - IE 5 doesn'tapply this, applying all of them regardless thus treating them as persistent. Again, this isnon-serious because it is pointless to have more than one preferred style sheet on a pageanyway.
IE 5 does not support alternate style sheets.
style attributeThe style attribute is given infinite specificity, rather than specificity of 100.Although this is a bug, it should not be fixed.
IE 5 incorrectly requires a space between @import and ""; for example, @import"css.css";wouldn't work.
CSS 1 defined a DELIM token, stating that all characters that couldn't form part ofselector tokens were delimiters. Thus, if IE 5 complied with CSS 1 or 2, it would > and + if itdidn't support them. However, it doesn't and prefers to ignore all unknown delimiting charactersand everything before them, treating this example (BODY + P), for example, as P.
The characters that are affected in CSS 2 are + and >; as CSSexpands, the problems will get worse.
H1 + P {margin-top: 0} /* + and everything that comes before it is ignored, sois considered to be P */
BODY > P {margin-left: 10pt} /* Treated as BODY P */
:link vs. :hoverThis is sorted differently from :visited vs. :hover - whereas :visited vs. :hover were sorted for the purposes of hovered over visited textas if they were both :visited:hover, these are sorted as if they were different, with:hover parsed as :link:hover and :link simply as it is.
As a result:
:hover {color: red;
/* background: transparent - initial value; not explicitly stated */}
A:link {color: green;
background: red}
In this example, hovered over unvisited links will be red in color, even though :hover has lowerspecificity than A:link and even though it precedes it for the order sort. They willalso have a red background, since no value is explicitly stated on :hover, so :link provides thevalue.
A:active applied to A:focus:active is incorrectly applied to tabbed-to links (not a major problem).
This means that although IE 5's link formatting is buggy, it is possible to use the bugs toachieve what you want. For example, it is possible to use the bugs to make distinctions betweenhovered over unvisited and visited links, etc. The temptation to exploit this is inevitable, butyou should take care to ensure that your links will look O.K. in future compliant browsers.
<A>)pseudo-classesThe CSS 2 specification permits this: A:link:hover. IE 5 treats this, which isinvalid at CSS 1, buggily, ignoring the first of the pseudo-classes (in this example, it would beapplied as if it just said A:hover).
Equally, it applies :link:visited as :visited and so on. Although Iwould not encourage invalid CSS, you could take advantage of this to exclude Opera and Netscapefrom link styling, subject only to the warning that Opera will apply :link:link (or any where both are the same), although it will not apply :link:visited.
IDsIt treats ids as case insensitive, whereas the HTML specification states that theyare case sensitive.
CLASSesIt treats classes as case insensitive, whereas the HTML specification states thatthey are case sensitive.
classes destroyedAlthough IE 5 does not support the use of multiple classes (e.g., <P class="onetwo">; matched by P.one.two), it does manage to do a fine job of destroyingthem, by interpreting multiple classes thus: ignore all but the last class, which is applied. E.g.,P.one.two would be parsed as P.two.
If you include Unicode characters 162-177 in classes, which are valid, IE 5 will not apply theclass. Furthermore, tokens solely comprised of such characters (or indeed other (truly) invalidcharacters) will destroy the ruleset, applying its content to every element on the page.
:first-lineIE 5 does not support :first-line.
:first-lineIE 5 does not support :first-letter.
IE 5.5 does not support vertical-align on :first-letter.
IE 5.5 does not support vertical-align on :first-line.
Although, as a pseudo-element, first-line selects the text that forms the first line (rather than the line itself), MSIE instead applies background behind the line box.
IE 5.5 makes the list marker red when selected with :first-line; this is wrong, since the marker is not part of the element, but is a marker (:before).
The CSS spec permits the use of the backslash for referring to special characters and the like,but IE 5 doesn't support any of these uses. This means that you should avoid using the backslash,unless to eliminate IE from your CSS.
simple_selectorIn CSS, comments are valid anywhere between tokens, but IE 5 does not support them inside simpleselectors (i.e., it doesn't support them in P/* comment here*/.class).
@import rules 5In addition, it does not support them in @import rules, ignoring the import if usedtherein.
IE 5 will ignore declarations that have comments immediately following the property (e.g.,color/* comment */ : red).
IE 5 will ignore selectors that have a comment immediately after the selector (e.g., P/**/{color: red}), applying them as HTML {declarations} (due to another parsing bug, explained
IE 5 applies the ex as 0.5em, which is wrong because the x-height of a font varies from font tofont, and the ex can be as little as 0.3em or as much as 0.6em.
According to the CSS specification, where there is no matching glyph for the characterrequested, a font that does include the glyph should be used instead. While IE applies this forcharacter references (such as ", or C), it does not doso for un-referenced characters, instead applying the glyph that is in the same position in thatfont as the requested glyph normally would be. Thus <SPANstyle="WingDings">H</SPAN> should result in a H, and WingDings should not be usedsince it doesn't contain any H's. This means that you should be wary of specifying fonts that lackthe appropriate glyph for unescaped characters.
lighterThis is buggy, not applying the next lightest font; for example, MS Arial, which containsweights corresponding to 100-500, 600, 700-800 and 900, gives a weight of 600 from an inheritedvalue of 900 in IE 5 and thence (correctly) to 100-500.
bolderThis is buggy, not applying the next boldest font; for example, MS Arial, which contains weightscorresponding to 100-500, 600, 700-800 and 900, gives a weight of 700-800 from an inherited valueof 100-500 in IE 5 and thence (correctly) to 900.
Although the CSS specification states that medium is the initial value of font-size, IE does not apply this, and makes small the initial value. This is a shamebecause IE's implementation of the font size keywords is otherwise excellent, but this one bugruins it.
Font-style: oblique is applied as font-style: italic, which is wrong - if one wanted oblique,failing which italic, one should write font-style: italic; font-style: oblique.
Font-variant: small-caps doesn't apply a small-caps font, even if one is available, but isapplied as text-transform: uppercase and a smaller font.
If font-variant: normal is applied to text that has been text-transformed, the text-transform isignored. Note that this does not apply to inherited font-variant: normal, but it does apply toinherited text-transform. E.g., it applies to:
<div style="text-transform: capitalize">
<p style="font-variant: normal">
Test text
</p>
</div>
But not to:
<div style="font-variant: normal">
<p style="text-transform: capitalize">
Test text
</p>
</div>
When a user font is specified (e.g., font: caption), it should reset all font values to normal,and should also reset line-height, and if the OS doesn't have values for these for the UI font,they should be set to their initial value. In IE, they only reset the values set by the OS - weight(i.e., boldness), style (i.e., italicity), size and family, but do not reset line-height orfont-variant. This means that you should specify line-height explicitly, and must specifyfont-variant explicitly if you use font-variant: small-caps.
IE 5 only supports the hyphenated user fonts (viz. small-caption, status-bar, message-box) if you(illegally) omit the hyphen. IE 5.5 on the other hand, supports both, but should only support the legal method.
While this is definitely a bug (albeit one caused by a change to CSS), it demonstrates theimportance of consistency - CSS does not hyphenate user colors, but it does hyphenate user fonts;that there should be some confusion is hardly surprising. This doesn't actually cause any problemsat all, provided you do this:
P {font: smallcaption; /* For IE 5 */
font: small-caption; /* For compliant UAs - doesn't mess up IE, since it interprets it as afont-family, but correctly ignores the declaration since font-size (required, else invalid) isomitted)
}
When an image is inline, it should increase the line-height if needed to fit it onthe line, but it should not decrease it. IE ignores this, and all line boxes that have inlineimages automatically and irreversably have line-height: normal.
normalNormal does not apply a constant <number>, as it probably should. Forexample, given font-size: 10px, line-height: normal is applied as 1.275<= n < 1.325, whereas font-size: 20px applies 1.1375 <= n < 1.1625. Thisisn't noted as a bug because the spec doesn't say that this wrong; however, I think it is.
IE 5 doesn't calculate the size of line boxes in the correct manner - it makes them equal insize to the largest value for line-height in the line box, whereas correct would be to make it fromthe top of the top inline box to the bottom of the bottom one.
Although this is technically a bug, it is a better approach than the 'correct' one, and as suchshould not be changed - it certainly won't cause anyone any problems.
When you set line-height to less than font-size, IE 5 will correctly honor the line-heightinsofar as the line box will be the specified height, but it will not correctly honor thebackground - it does not draw backgrounds that are smaller than font-size, so for example <Pstyle="background: red; line-height: 4px; font-size: 16px"> would result in a background in eachline box that would be 16 pixels high.
Where a text-indent is specified that exceeds the element's width, IE 5 increases thepadding-right of the element to compensate. This is unlikely to be a problem since text-indents donot typically exceed a few percent.
Text-decoration is inherited rather than applied (as the spec states) as though descendantelements should have the text-decoration of their parent (i.e., the same color, thickness, etc.).This means that the text-decoration will be the color of the descendant rather than of theancestor, and also that text-decoration: none will work on descendant elements to suppress theancestor's text-decoration, which is clearly a nonsense.
IE incorrectly 'inherits' text-decoration. For example, P {text-decoration: underline} P.class{text-decoration: line-through} would apply both of them to the P.class.
This bug, although highly unlikely to occur, can be avoided as follows:
P {text-decoration: whatever}
P.class {text-decoration: whatever-else}
Becomes:
P {text-decoration: whatever}
P.class {text-decoration: none}
P.class {text-decoration: whatever-else}
N.B., not:
P.class {text-decoration: none;
text-decoration: whatever-else}
This bug (and its workaround) would also apply where an element had both a class and an id, andthey had differing text-decorations.
IE 5 inherits text-decoration to block elements, whereas the CSS spec states that is onlyinherited to inline descendants.
This doesn't work.
IE 5 does not ignore text-decoration: blink correctly. For example, given text-decoration:underline; text-decoration: blink, it should ignore the blink declaration because it doesn'tsupport it and apply the underline, but it doesn't, applying no text-decoration at all. Note thatthis is in a sense non-serious because it is highly unlikely that anyone would have this kind ofdeclaration anyway. This bug also means future values of text-decoration will probably causeproblems.
This doesn't work.
Sub and super are the only supported values on text.
This aligns the middle of the element's box with the baseline of the parent box, not thebaseline plus half the x-height as it should. (In IE 5.5 it aligns with an arbitrary, rather than calculated middle.)
Not supported on images or form elements.
Only aligns with the baseline, not the bottom as it should.
IE 5 does not support vertical-align lengths or percentages.
Vertical-align: super and sub increase the height of the background. For example, <SPANstyle="vertical-align: super; background: blue"> would (correctly) raise the baseline of theSPAN to the correct position for superscripts, but it would draw the background from the bottom ofwhere it would orginally have been to the top of where it ends up.
white-spaceWhite-space doesn't work.
When uppercased, ƒ results in a missing character glyph. This is incorrect because ifcharacter cannot be transformed, it should be left as-is.
Margins and padding don't work on inline text elements, but margins (not padding) do work onIMG, and both work on FORM elements.
Although the hspace and vspace HTML attributes (valid on the OBJECT and IMG elements) should beequivalenced by the margin properties, in IE 5 they are not, being applied in addition tothe margin rather than instead of it.
Padding is not applied to empty elements.
If you set margins to auto, they are replaced with 0, which is wrong when both margin-left and margin-right are auto or when either margin-left ormargin-right is set to auto and width is set to a value other than auto, or when margin-right isnot 0 and margin-left is auto.
If you set a negative margin right on an element and it causes its right edge to go to the rightof the right edge of the canvas, the canvas will not be extended by adding or extending a scrollbar, and hence the content will be cut off.
margin-right not ignored when width setWhen width is set, since IE 5 doesn't support auto, it should ignore margin-right,setting it to such a value as to make it fit the containing block, but doesn't, applying itregardless.
When a DIV has padding-top or padding-bottom set on it, its first andlast child's backgrounds will color in the padding. For example:
<div style="padding: 2em;">
<P style="background: red;">
</P>
<P style="background: green;">
</P>
</div>
Would set DIV's padding-top to red, and its padding-top to green. Thisis of zero consequence unless either element has a border.
Note that the right and left padding would (correctly) be transparent.
Borders are unusable on BODY, being applied outside of the scroll bar, thus meaning that theborder is drawn outside of the scroll bar.
As a result, they should be avoided.
According to the CSS spec, margins are outside of borders. IE 5 does not apply this, applyingmargins inside borders on BODY.
Borders are badly broken on HTML as well, though in a different way. They are only applied whenBODY does not have a border (i.e., BODY's border is renderd on top), and the rest of the time theyare applied in a buggy way that destroys the page.
As a result, they should be avoided.
IE 5 does not support borders on inline non-replaced elements; however, it does support them onreplaced elements.
Where a border width is set and width is explicitly set, it is deducted from the element'swidth, rather than added to the margin-right. Whilst this is not likely to be significant when youhave a thin border, it will be when you set a big one, as is likely with 3d borders.
Because IE applies the 3D border styles by applying a darker section, all of the followingborder styles will appear as solid when the border color is black or very dark:
The dotted and dashed border styles are not supported, being rendered as solid.
Because this document is very long, it has been split into two parts to reduce download times.To continue to the next section, which considers widths and heights, tables, lists, floats, formsand more, click here.
Copyright ©RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.