views:

47

answers:

2

This is a weird CSS issue I was experiencing while trying to fix a footer that rendered properly in IE 6 but failed to render properly in IE 7. Here's what the issue was.

There is this css class, clearer, shown below:

.clearer {
    clear: left; 
    line-height: 0; 
    height: 0;
}

In the JSP/HTML output, there were either:

<div class="clearer"></div>

or

<div class="clearer" />

in various places.

This is inside a JSP page that gets wrapped with external HTML. The gist of it is (the technology is called Sitemesh for those who are interested or know of Sitemesh):

<header>
<body with specific page content>
<footer>

Now, each piece of these have specific div elements, so it could be represented as such:

<div class="header"> <!-- header stuff -->
</div>
<div class="pageContent"> <!-- page content goes here -->
</div>
<div class="footer"> <!-- footer stuff -->
    <div class="firstFooterDiv"></div> <!-- some footer stuff -->
    <div class="secondFooterDiv"></div> <!-- some other footer stuff -->
</div>

When the pages rendered in IE 6, everything was fine. But with IE 7, the footer floated to the top for some reason. Investigating using Opera Dragonfly (which also had the issue), I found something similar to this in the DOM:

<div class="pageContent"> <!-- page content goes here -->
    <div class="clearer">
        <!-- actual page content?!!!! -->
    </div>
    <div class="footer"> <!-- footer stuff -->
        <div class="firstFooterDiv"></div>
    </div>
</div>
<div class="secondFooterDiv"></div> <!-- some other footer stuff -->
</div>

Somehow, that clearer div, although it was closed, behaved as an open div?! This forced the footer stuff partially into the holder for the main page content. On IE 6, the effect of this does not happen.

Any idea why this occurred?

Note that the page was valid according to XHTML-1.0 transitional, so it was not a page validation error - the divs do match up - although they match up incorrectly in the DOM!

EDIT: when clearer was removed, the pages look fine and this issue does not occur - it's only when those useless divs are in that this happens.

A: 

Empty elements with the closing "/>" is appropriate for XHTML/XML but not HTML and is treated as "tag soup", perhaps confusing the inspector. Also, empty divs are handled differently, collapsing into nothingness if they're not given a size.

Rob
Well, it's valid XHTML transitional as I described. Furthermore, what do you mean by "collapsing into nothingness"? Surely that's different than containing a div that appears later inside of itself?
MetroidFan2002
+2  A: 

I'd definitely point the finger of suspicion at the self-closed divs. Although the validator may have said it's OK, and I the specs say it's OK if you're sending the document as XML, it causes all kinds of problems related to browsers' display engines and interpretation of the specs and you're much safer not to do it.

There's a good discussion of it here in question id 348736.

David Heggie
I agree, I once spent a good half day tracking down a bug that turned out to be a self closing div and ever since have stayed away from them.
Bertine
By self-closed divs I'm assuming you mean a div such as div /, not div > / div. But the same problem occurs in documents that have div > / div as well (an opening, then an explicitly closed div). Any ideas why that's happening?
MetroidFan2002