Friday, October 1, 2010

Common fixes for Internet Explorer 6 and 5

Internet Explorer 6 was a step up by Microsoft, away from the disaster (from a standards
point of view) that was Internet Explorer 5.x. That said, it still had plenty of shortcomings
of its own, the vast majority of which were dealt with when Internet Explorer 7 finally
jumped on in. Any fixes from the Solution sections that follow should be added to an IE
6-and-below-specific style sheet (see the conditional comment earlier that begins <!--[if
lte IE 6]>).

Fixing min-width and max-width
Problem:
The browser does not understand min-width and max-width, thereby causing
problems with semiliquid layouts that have minimum and maximum widths, rather than
set width values.
#wrapper {
min-width: 700px;
max-width: 1100px;
}

Solution: Use a proprietary IE expression to enable Internet Explorer to emulate the functionality
of min-width and max-width. In the code, the expression essentially states that if
the browser window width is less than 702 pixels, set the wrapper width to 700px (these
values—702 pixels and 700px—are numerically different to prevent Internet Explorer 6
from freezing); if it’s more than 1102 pixels, set the wrapper width to 1100px; and otherwise
set it to auto.
#wrapper {
width: expression(document.body.clientWidth < 702? "700px" :
å document.body.clientWidth > 1102? "1100px" : "auto");
}

Double-float margin bug
Problem: The browser doubles the value of any margin in the same direction as a float. For
example, in the following code, the right-floated boxout with a margin-right value of
30 pixels would actually be shown in Internet Explorer 6 and below to have a 60-pixel
margin-right value. Note that this problem only occurs for the first float in any float row.
.boxout {
width: 300px;
float: right;
margin-right: 30px;
}

Solution: Override the margin-right value, and halve it.
.boxout {
margin-right: 15px;
}
Alternatively, if appropriate, display: inline can be defined in the original CSS rule,
which results in the IE-specific override becoming unnecessary.
Expanding boxes

Problem: An element with a string that’s too wide for it doesn’t break out of its container;
instead, the browser stretches the container to contain it.

Solution: Use the word-wrap property with the break-word value, assigning it to the relevant
container.
#sidebar {
word-wrap: break-word;
}
Note that this is a CSS 3 property that’s not particularly well supported, and while it fixes
the layout, it doesn’t emulate the correct standards-compliant approach of the string
breaking out of the box—instead, it breaks the string into a number of separate lines. An
alternative is to set overflow on the container to hidden, thereby hiding the overflow and
returning the layout to normal, at the expense of not being able to see the long string.
Generally, when you come up against this problem, it makes sense to rework your string,
because while the layout won’t be affected in standards-compliant browsers, it will still
look bad.
Internet Explorer 5.x sometimes also expands a box when italics are used for some of the
text, although the problem is somewhat random. Setting overflow to visible for the container
often fixes the problem. Alternatively, setting the value to hidden crops the unruly
few extra pixels.

The 3-pixel text jog
Problem:
Inline content next to a floated element
is pushed away by 3 pixels. In the
depicted example, the content in the dotted
line has a 3-pixel jog in the text that appears
under the floated element.

Solution: Apply the “Holly hack,” a 1% height
value to the relevant containing element(s).
See three-pixel-jog.html in the chapter 9
folder of the download files. Try removing
height: 1%; from #textWrapper to see how
the page looks without the hack.

No comments:

Post a Comment