Section E - color and background bugs

Color formats

Rgb() format

Bug 1: not supported

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.

Inherit and UI colors

Bug 2: inherit and user interface colors destroyed

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.

Concepts

Color

Bug 3: color not supported on IMG

IE 3 does not support color on the IMG element (i.e., to specify the color of alt text).

Backgrounds

Bug 4: badly supported in linked style sheets

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.

Bug 5: rendered on block as if they were inline

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.

Bug 6: transparent

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.

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. */

Background images

Bug 7: background images not supported in LINKed style sheets

IE 3 does not support background images in LINKed style sheets at all.

Bug 8: doesn't work on IMG

You can't give IMG a background different to that of BODY (i.e., for alt text purposes).

Bug 9: none not supported

Background: none is not supported.

Bug 10: quotes 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).

Bug 11: absolute urls

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.

Bug 12: animated backgrounds not supported

IE 3 does not animate animated backgrounds.

Background positions

Bug 13: Lengths on background positions unsupported

IE 3 does not support lengths on background positions.

Bug 14: background positions of 0 destroy background

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.

Bug 15: background positions destroy background repeats

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.

Bug 17: background position when only one specified

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.

How can I get it to work then?

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!.

Bug 18: background positions don't work on most elements

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).

Background attachments

Bug 19: background: fixed

The fixed background attachment only works on HTML and BODY.

Background repeats

Bug 20: background repeats only work on BODY/HTML and TABLE

IE 3 only support background repeats on BODY, HTML, TD and TH.

Properties

background-image

Bug 21: not supported

IE 3 does not support this, but it does support it via the background shorthand.

background-color

Bug 22: not supported

IE 3 does not support this, but it does support it via the background shorthand.

background-attachment

Bug 23: not supported

IE 3 does not support this, but it does support it via the background shorthand.

background-repeat

Bug 24: not supported

IE 3 does not support this, but it does support it via the background shorthand.

background-position

Bug 25: not supported

IE 3 does not support this, but it does support it via the background shorthand.

Fixing it

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!

Section F - Margin bugs

Margin-top

Bug 1: badly supported inline

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>).

Bug 2: inherited

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.

Bug 3: doesn't work on BODY

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:

Example

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:

P

BODY

H1-H6

BLOCKQUOTE

OL

UL

PRE

TABLE

FORM

DIV, if it contains any of the above elements

Because of inheritance, you cannot apply margin-top to DIV if DIV
contains any of these elements.

Bug 5: % buggy

% 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.

Margin-bottom

Bug 6: Not supported

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-left and margin-right

Bug 7: margin-right unsupported inline

Margin-right does't work on inline elements.

Bug 8: margin-left unsupported inline

Margin-left only works on inline elements where they are the first bit of content in their
containing block.

Bug 9: interpreted relative to the viewport

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).

Bug 10: auto unsupported.

Auto margins are interpreted as 0, which causes seriously problems, as explained above.

Bug 11: %

% are incorrectly calculated relative to the element's width rather than to the containing
block's width on margin-left and margin-right.

Bug 12: intepreted as additional to default

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.

Bug 13: first margin shorthand value applied to all four sides

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.

Section G - Unsupported properties

The box model

padding-left

padding-right

padding-top

padding-bottom

padding

border-left-width

border-right-width

border-bottom-width

border-top-width

border-left

border-right

border-bottom

border-top

border-style

border

border-color

The visual formatting model

height

width

display

clear

float

List-style properties

list-style

list-style-position

list-style-image

list-style-type

Part 2 - Element-specific bugs

Section H - Form bugs

FORM

Bug 1: background-image

You can't give FORM a background-image unless you enclose it in a TABLE and apply it to
that.

Form elements other than FORM itself

Bug 2: style doesn't work

Styles don't work on form elements except for backgrounds as stated below.

Bug 3: background

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.

Bug 4: backgrounds on SELECT

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.

Bug 5: text-align applied to TEXTAREA is applied as affecting the containing block

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.

Section I -Tables

Tables

Bug 1: Inheritance from LINKed style sheets

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.

Bug 2: background doesn't work on TR

You can't give TR a background.

Bug 3: Inheritance from LINKed stylesheets

Into, and after, an HTML <TABLE>, the following styles do not inherit if
specified in a LINKed style sheet.:

color

line-height (although the margin-top: 0 bug associated with it does)

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.

Bug 4: text-align applied to TABLE

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.

Bug 5: unclosed P element prior to table inherits into table

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.

Bug 6: captions backgrounded by tables

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.

Bug 7: margins applied to table cells as horizontal padding

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.

Bug 8: margins not applied to captions

IE 3 does not apply margins to captions

Bug 9: horizontal margins not applied 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>

Bug 11: text-align doesn't work on captions

Text-align doesn't work on captions in IE 3.

Bug 12: BODY's margins inherited to table cells

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.

Section J - list item bugs

Bug 1: background applied behind list marker

IE 3 applies LI's background to list markers, but this is incorrect.

Bug 2: text-align moves marker glyph

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.

Section K - Horizontal rule bugs

Bug 1: background of horizontal rules applied to their margins

If you apply a background to horizontal rules, it will be applied to the rule and its unsightly
- a most unsightly effect.

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.

Whitespace at the beginning and end of quoted fonts is ignored, even though it shouldn't
be.

Colors without the # sign are applied.

If fewer than 3 digits are supplied, they are padded out with zeros to make 3 digits and
appplied as a 3 digit color.

If fewer than 6 but more than 3 digits are supplied, they are padded out with zeros to make 6
digits and applied as a 6 digit color.

If more than 6 digits are supplied, the surplus is abandoned and the remainder is applied as a
6 digit color.

If the unit is unknown (e.g., 1dog or 1cabbage), Internet Explorer 3
interprets it as px. Thus margin-left: 50dogs would be 50px.

If a number is omitted, IE 3 defaults to 0.

If the unit is omitted, IE 3 defaults to px. Thus BODY {margin-left:} would be interpreted as
BODY {margin-left: 0px}.

Em and ex are applied as pt, bizarrely.

Keywords in quotes aren't valid, but IE 3 applies them.

If more than four margin values are provided, IE 3 applies the first four.

It allows comments inside URIs, but this isn't valid, since the uri token includes w*, and w is
a macro, not a token.

If the final } is omitted, but the ; is included, the style is applied.

If a selector is omitted, it implies
the universal selector. Thus {color: red} is equivalent to * {color: red}

IE 3 allows font: shorthand declarations that include neither size nor family, though it
doesn't allow declarations that just include family.

It parses Courier\ New as Courier New

It applies text-align to inline elements, (badly and incompletely) transforming them into block
ones.

It applies text-indent to inline elements, (badly and incompletely) transforming them into
block elements.

It ignores the case of font names, thus applying Arial when arIaL is given.

It fails to treat the first instance of </ as terminating the style block.

It applies Times New Roman when Times is requested (what if you want Times but not Times New
Roman?).

It permits the use of // as comment delimiter

It allows % to be mixed with position keywords on background, but this is invalid and should be
ignored.

It fails to ignore selectors that are grammatically incorrect unless the invalid part of the
selector is at the end; for example, it doesn't ignore P & X, .four {color: red}, which is
invalid CSS 1, but it does ignore .four, P & X.

It allows character references in IDs, but they are only valid in classes.

It allows extraneous white space inside font names.

It allows spaces between numbers and their units, but this isn't valid.