Skip to page content or skip to Accesskey List.
Search evolt.org
evolt.org login: or register

Work

Main Page Content

MSIE6 bug with floating divs and spacers

Rated 4.24 (Ratings: 9) (Add your rating)

Log in to add a comment
(28 comments so far)

Want more?

 
Picture of raphael

Raphaël Mazoyer

Member info | Full bio

User since: November 21, 2001

Last login: May 20, 2007

Articles written: 4

Microsoft Internet Explorer 6 running on a Windows system has a very annoying display bug when rendering an HTML page that uses Cascading Style Sheets to define divs as floating and adding a spacer div at the bottom with the setting clear: both attribute. If you've been using Marc Newhouse's great Practical CSS column, this may have affected you already...

The problem

Consider the following style sheet:

.spacer {
  clear: both;
}

.container {
  border: 1px #999 dashed;
}

.item {
  float: left;
  background-color: #ccc;
  padding: 5px;
  margin: 5px;
}

.main {
}

.main2 {
  background-color: #eee;
}

And the following HTML file:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>title</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<link rel="stylesheet" href="style.css" type="text/css"/>
</head>

<body>
<div class="main">
  <h1>Title of the page</h1>
  <div class="container">
    <div class="spacer"> </div>
    <div class="item">One</div>
    <div class="item">Two<br/>bis</div>
    <div class="item">Three</div>
    <div class="spacer"> </div>
  </div>
</div>
</body>
</html>

... which validates as XHTML and CSS.

View it in any CSS-compliant browser, you'll see the same results (see screenshot).

Now consider another HTML file, identical to the first one, with the exception that the first div is set to the class .main2. The only difference is that its background-color attribute is set. When I look at it with IE6/Win2k, I don't see "Title of the page", it just isn't visible. Space is reserved for it, but the words aren't there. If you don't have IE6/win, see this screenshot.

OK, we've seen the reason. Now let's see some weird behavior: scrolling. When you scroll down then back up your affected page, the display is properly redrawn! Try it for yourself on the second example, or see this screenshot. (Note: the actual files differ from the code above, as I've added some &lt;br&gt;s to allow you to scroll easily. It does not otherwise affect the demonstration.)

The solution

Brian G. Vallelunga has provided me with the fix: explicitly set the position attribute of paragraphs to relative. Practically, add the following rule to your style sheet:

h1, h2, h3, h4, h5, h6, p {
  position: relative;
} 

See it in action, the way it should be (note the different CSS file). It still validates as XHTML and CSS, but I'm not sure how respectful it is of the spirit of the thing: feel free to contribute comment if you have some insight in this matter!!

But yes, it's that simple :-)

A EMMA/Digital Media Design graduate from the HKU in Holland, Raphaël co-founded the now-defunct web consulting outfit Splandigo. My personal site: Petit Bourgeois: commentary about web building. I have left Splandigo in August 2005, and have joined Weathernews in Makuhari, Chiba prefecture. I coordinate the work on our 30-odd European mobile and web services. You can reach me at evolt.contact [at] direct.phase4.net.

There are much worse bugs than that...

Submitted by tomgilder on May 13, 2002 - 08:45.

See http://tom.me.uk/2002/2/ie6css.html for more hellish IE6 CSS

login or register to post comments

Honestly

Submitted by chozsun on May 13, 2002 - 11:41.

I could give a rat's ass about IE dispite how many people use the browser (mostly out of ignorance). If it validates as CSS and HTML and IE does not display properly, that is to the fault of IE, not me.

login or register to post comments

Works

Submitted by Robbes on May 13, 2002 - 13:31.

Well, I can see the title directly after opening the document. Tested with IE 6 running on a Windows 2k Pro having SP 2 and all other patches applied.

login or register to post comments

Re: Works and honestly

Submitted by raphael on May 13, 2002 - 16:33.

I checked it again just now in my IE6 with all patches applied on Windows XP, and it is still appearing with the display problem. But I did hear from a number of people that it was a platform-related problem (video cards? I'm not sure at all about this) and that it didn't happen on all configurations. Regarding the relevance of caring about this at all, well, yeah, I can see your point, but depending on the context, you may need to make sure it works for everyone...

login or register to post comments

Re: Honestly

Submitted by glaven on May 14, 2002 - 02:01.

chozsun,

for the same reason the author (raphael) presented this fix is the same reason people have used javascript for determining which browser is viewing the page for the past however many years.

although the current incantation of most browsers are generally conforming to web standards these days there are obviously still bugs. and unfortunately it's IE this time as opposed to the red headed stepchild, nutscrape. if somethign works in one browser but not in another, whether it be a shotty program (netscape), or bugs (IE) you still need to come up with a workaround.

login or register to post comments

not so fixed

Submitted by me3dia on May 14, 2002 - 21:27.

Well, I tried this fix on my site's CSS, and it worked great -- in WinIE6. When I took a look at my page at home on my MacIE5, the text wasn't there -- blanks where it should be. Taking out the code fixed the problem.
Is this a CSS agreement issue, or a non-support issue? Here's a screenshot, a copy of the broken page, and an alternate CSS with the "fix" in.

login or register to post comments

MacIE 5 bug activated by this workaround

Submitted by CodeBitch on May 16, 2002 - 19:02.

Me3dia, I think you have encountered the relative-position linespacing bug in Mac IE 5. I didn't realise this affected all relatively positioned blocks, not just DIVs, and I will update the MacEdition Guide to CSS bugs in Mac IE 5 accordingly. There are a couple of workarounds suggested in the Guide, or you could use the Sam's Mac Hack or the @media section hack to hide that specific style from Mac IE 5. Note, however that Sam's Hack only works for selectors that start with punctuation (classes and ids), so you might have to change your style rule selector to something like #blogsection h1, #blogsection h2 .... I'm always happy to receive bug reports for Mac IE5, OmniWeb or iCab to add to MacEdition's resources on the subject .

login or register to post comments

MacIE 5 bug activated by this workaround

Submitted by phiw13 on May 17, 2002 - 06:54.

I can confirm that it doesn't work with IE5 mac; the lineheight of paragraphes and headings got pretty interesting. The @media all hack seems to be the best work around, especialy if you are dealing with a complex stylesheet. But I'm still checking on a site that covers several hundred pages.

login or register to post comments

How to see the title and another IE6 bug

Submitted by Xanadu on May 17, 2002 - 09:06.

In the example without the fix, I noticed there was a lot of white space at the bottom, after using Select All to highlight any text. So I scrolled down to see what was there, but when I scrolled back to the top, the Title text appeared!

I have also come across a recent bug in IE6 that seems to be down to timing (just like the A List Apart menu cut-off bug). I have a set of divs with coloured backgrounds and a simple 1-pixel border set via a separate stylesheet. Sometimes, parts of the border would not be drawn, in random places. But switch to a program, then back to IE6 and the borders were there!

I took out some Javascript and that solved it. Until I activated some PHP in the file and the fault returned. I'm now thinking it's the COMMENTS tags that are pausing the browser for a fraction of a second, so they too have been removed and now the fault seems to have gone. And doesn't javascript code have comment tags around it?

I've also been told it's caused by padding or margins, but who knows? Watch out for this bug!

login or register to post comments

Scrolling

Submitted by raphael on May 17, 2002 - 12:27.

Indeed, scrolling within the page or switching to another program and then back to your browser window properly refreshes the page. But you can't really ask your users to scroll, can you? ALA mentioned this article yesterday, and pointed out the fact that the bug was described over a year ago and still hasn't been fixed by Microsoft, because they aren't able to reproduce it...

login or register to post comments

Better relative positioning fix

Submitted by BigJohn on May 19, 2002 - 22:16.

I have found that the best way to handle this mess is to place the relative positioning on the floats and their container. Non-floated elements in the container should be left alone. See this page for a working example of this: http://users.rraz.net/mc_on_the_rocks/testpage/bughouse.html

login or register to post comments

Better relative positioning fix [correction]

Submitted by BigJohn on May 19, 2002 - 22:39.

Actually, I did not mean div.container, but rather div.main should get the relative positioning. Sorry.

login or register to post comments

Fixes don't work for me

Submitted by peterwhittleton on May 27, 2002 - 07:56.

I have a v. similar problem. I've chopped my code down to:
a) a small stylesheet ...

body {
margin: 10px 10px 10px 10px;
padding: 0px;
color: black;
background-color: yellow;
}

#page {
background-color: white;
}

#right {
float: right;
width: 250px;
background-color: red;
}

#main {
margin-right: 250px;
background-color: cyan;
}

#bottom {
clear: right;
background-color: green;
}

b) and a small piece of html ...

<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
   <link rel=stylesheet type="text/css" href="basic.css">
</head>
<body>
   <div id="page">
     <div id="right">R<br>I<br>G<br>H<br>T</div>
     <div id="main">M A I N</div>
     <div id="bottom">B O T T O M</div>
   </div>
</div>

</body>
</html>


Simple, right? And it works fine in Netscape 6 (.2.3), but in IE (both 5.5 and 6) the 'clear' is screwing things up. But I nead the clear because I don't know the height of the 'main' or 'right' blocks and I want the 'bottom' block to come below whichever has the greater height (i.e. a footer). [btw without the body margins it's ok, but the designer wants margins!].

Don't you just hate this crap? The reason I switched to css was to get away from all this. AArgh.

Anyway, any idea of a solution? I've tried playing with position:relative with no luck.

Peter

login or register to post comments

Coddling IE

Submitted by BigJohn on May 27, 2002 - 08:40.

One IE trick I've recently found is to place inline elments after block elements that are interacting with a float. A non-breaking space will do. I think it occurs when the block level element ends higher than the bottom of the float. IE just feels insecure without a linebox in there. And can we blame it? Floats are really scary!

login or register to post comments

Solution

Submitted by Xanadu on May 27, 2002 - 10:10.

Add a width to the page div. Then it works in IE!

login or register to post comments

Magic!

Submitted by peterwhittleton on May 28, 2002 - 02:09.

You're right it works, and for once it doesn't break Netscape either. Now why didn't I think of it ...
Thanks for your help, much appreciated.
Peter

login or register to post comments

How I solved this one

Submitted by Xanadu on May 28, 2002 - 02:18.

I tried everything to get your code to work. I scoured the W3C site for clues in the definition of clear and float. Finding nothing there, I did what I usually do in these situations, and that is to try anything! Moving the order of the divs around (ahem), commenting out the padding and the margins, testing it in all 3 major browsers. (Hey, your page works in Opera 6!) But nothing worked.

Then, glancing at the css again, I thought 'What doesn't the faulty div have that the others have?' All I could think of was a width attribute.

Of course this means you have to specify the width of the page. It's a bit like Netscape requiring the width and height to be set on divs or they fail. Or IE6 demanding that you specify pixels for the values, or all your divs are at the top of the screen! (A change from IE5.5 to 6.)

Like all coding, it makes sense. But odd how the other browsers don't require a width setting for the page div in your example!

No doubt we'll find more discrepancies with Netscape 7. Anyone used it yet?

login or register to post comments

Setting width

Submitted by peterwhittleton on May 28, 2002 - 02:34.

> Of course this means you have to specify the width of the page.

No problem, I just set it to 100%. Like you I tried a lot of different things (some pretty unlikely) to get this to work but I didn't follow it through like you did.
So again, thanks.

Peter

login or register to post comments

Window XP Center Tag Positioning Bug

Submitted by latino on August 1, 2002 - 20:37.

We have detected a positioning bug which occurs in Window XP running IE 6 browsers. When one encloses a table withing the standard html center tags and define the valign attribute of cells as valign="top" the textual context in the cells may not be rendered aligned but centered; ie, the center tag overrides the table cells vertical alignment. Since this effect does not occur in Windows 98 running IE 4+ or 5+ browsers, we like to call it a bug. Changing the cell attribute from valign="top" to align="left" above, causes the center tag not to override the align="left" attribute of the cell. This, however, may not be appropriate in some positioning templates, specially in those were an overall top alignment is required.

login or register to post comments

Why does text move in mac IE?

Submitted by dhtmlkitchen on August 17, 2002 - 18:55.

In mac IE, text will move around until it is settled into the correct place. I don't know what causes this. I don't know how to fix it either. The text will move when you hover a link or during some dhtml animation. The index page of my website is a perfect display of the bug, although I wish it weren't. I couldn't find a fix by searching google, but I did find this site. Please post if you know the answer.

login or register to post comments

Text becomes unselectable

Submitted by bearwalk on October 29, 2002 - 10:45.

I tried the article's workaround:

h1, h2, h3, h4, h5, h6, p {
  position: relative;
}

(And a few more tags) That made the elements visible again, but now some of them can't be selected with the mouse. I can only select them using CTRL+A.

login or register to post comments

class vs id

Submitted by tlyczko on December 31, 2002 - 11:47.

i had this problem too, i was using an id and the heading wasn't showing...so i added a class to the style sheet that was the same as the id, then used the class name instead of the id name for the div that was not displaying the header, and the problem went away, didn't even know about this relative business... :) tom

login or register to post comments

Re: Window XP Center Tag Positioning Bug

Submitted by Kosmos.R on May 31, 2003 - 19:10.

I've always thought that those tags would eventually be faded out of the picture (center, bold, italics, etc) in favor of style attributes. So, you should actually be aligning tables in the table tag and not wrapping tables in center tags. If you follow this practice for the rest of your documents, then I believe you shouldn't have a problem with table alignment in any browser. You cannot assume, so therefore you should add attributes to your tag when it is important. I know it's a bitch, but if you work efficiently anyway (using templates, libraries, includes, stylesheets and various methods to reduce replication and improve site maintenance) then it won't be much of a hassle. I'd prefer to work just an extra bit to not worry about browser compatibilities then having to fret about every single problem because I decided to assume what should be compliant at a minimal should work (I think those minimal compliance is BS anyhow. Next time W3C should just put out absolutes, like requiring end tags for just about everything). I think this applies to the article above as well ...

login or register to post comments

Re: Window XP Center Tag Positioning Bug

Submitted by Kosmos.R on May 31, 2003 - 19:11.

I've always thought that those tags would eventually be faded out of the picture (center, bold, italics, etc) in favor of style attributes. So, you should actually be aligning tables in the table tag and not wrapping tables in center tags. If you follow this practice for the rest of your documents, then I believe you shouldn't have a problem with table alignment in any browser. You cannot assume, so therefore you should add attributes to your tag when it is important. I know it's a bitch, but if you work efficiently anyway (using templates, libraries, includes, stylesheets and various methods to reduce replication and improve site maintenance) then it won't be much of a hassle. I'd prefer to work just an extra bit to not worry about browser compatibilities then having to fret about every single problem because I decided to assume what should be compliant at a minimal should work (I think those minimal compliance is BS anyhow. Next time W3C should just put out absolutes, like requiring end tags for just about everything). I think this applies to the article above as well ...

login or register to post comments

Simpler test case and solution

Submitted by dracos on August 28, 2003 - 15:43.

No spacer div is necessary for the bug to occur, and any element can be floating inside (even using HTML align on an img rather than CSS's float) not just a div. I have come up with what I think is a better solution to the problem rather than "position: relative": simply specifying line-height on the container causes the problem to go away. I have put up a page at http://www.dracos.co.uk/web/css/ie6floatbug/ with explanation and examples.

login or register to post comments

Also works with a form bug within a floating div

Submitted by invent on November 8, 2004 - 12:19.

I had a problem where a form select drop-down had some mysterious text appearing (text that was within an option tag) below the div... just a few characters:
Choose Category Type Main Categories Sub Categories Sub Sub Categories

The above appeared like this:
Choose Category Type Main Categories Sub Categories Sub Sub Categories
gories

"gories" was definitely the last part of the last option.
The text appeared outside of the background colour that definied the div... most odd.
But happily fixed by having position: relative; in the class.

So thanks!

P.S. complaints about IE... tiresome! In the real world most people use it. In the real world, clients would not pay for a website on which they and their visitors couldn't see anything! Microsoft are successful... get over it and try to become successful yourself!

login or register to post comments

oops..

Submitted by invent on November 8, 2004 - 12:23.

didn't read the allowed code bit...

Imagine this:

select
option value=something
option value=categories
end select


The above appeared like this:
select
option value=something
option value=categories
end select
gories

"gories" was definitely the last part of the last option.
blah blah

login or register to post comments

Lineheight

Submitted by Damage on January 5, 2006 - 19:21.

Lineheight of paragraphes and headings got pretty interesting. The @media all hack seems to be the best work around, especialy if you are dealing with a complex stylesheet. But I'm still checking on a site that covers several hundred pages.

DAMAGE

login or register to post comments

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.orgEvolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.