I found a reference to this bug on the Channel9 Wiki page Internet Explorer Support for CSS (look for the bullet "Incorrect Margin Calculations"). No work-arounds are provided.
See the demo code
Tested: IE 6 on Windows XP SP2 (6.0.2900.2180.xpsp_sp2_gdr.050301-1519)
The only work-around I've found so far is to place positioned objects at the bottom of the page. I'll need to analyze the content to determine if this is an appropriate solution, though, since I've been trying to keep the CCMS site more aligned to the web ideal for design (semantic rather than visual). It's possible to get the desired spacing using padding instead of a margin on the affected object, but if we were ever to make modifications to the design that involved background colors or images we'd run into problems.
Update 2005-08-18:
I decided to use a float on the menu to get around the problems I was encountering. This led to another problem, but this time with Firefox. The navigational menu was being positioned further down on the screen than I expected. Turns out I was running into my old friend the margin-collapse rules. Since the first element on the page was set to
display: none and the second element set to float: left, it appears the third element was actually interpreted as the first in the flow of the document.According to the W3C spec:
Two or more adjoining vertical margins of block boxes in the normal flow collapse. The resulting margin width is the maximum of the adjoining margin widths.The "body" box and the "content" box come under this rule. Since the content box has a 150px top margin, it was collapsing with the body to have a shared 150px margin. Thus, when the top margin was determined for the navigational menu it was based on the assumption of a 150px margin on the body.
See the demo code
Tested: Firefox 1.0.6 on Windows XP SP2
Browser String: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
To work around the problem I gave the body a 1px padding.
Update 2005-08-24:
I've completed the updates to the CCMS stylesheets. I had to scratch some visual updates for Nav4 when I realized they made the site's pages unprintable. In the end, Nav4 continues to use the same bare-bones style as in the previous iteration.
Additionally, I had to scrap any efforts to make the CSS more Contribute-friendly. After extensive testing I've come to the conclusion that Contribute's CSS support in editing mode is almost non-existent. I've recommended an update to Contribute 3, which appears to be much improved in this repect.
