PHWinfo - Afficher un message - IE compatible way of forcing footer to bottom of page?

31/03/2008, 01h14

On 2008-03-30, Dave Rado <dave.rado@dsl.pipex.com> wrote:
[...]
> I've succeeding in getting my footer to stay at the bottom of the
> viewport if the height of the webpage's content's is less than the
> height of the viewport; and in staying at the bottom of the webpage if
> the height of the webpage's content's exceeds the viewport's height;
> by using the method I linked to earlier. See my mock-ups at
> http://tinyurl.com/2urjf2 (short content) and at http://tinyurl.com/393k5n
> (long content). However, in order to get the three icons above my
> "document page" to appear in the correct place in all browsers, I had
> to add the following IE conditional comment:
>
>
>
> (As opposed to a top value of -8px that is required in all non-IE
> browsers and in IE8 beta, according browsershots.org).
>
> That is, in IE7 and below (but not in IE8), the TopOfPageIcons div is
> positioning itself relative to the top of the webpage; whereas in all
> non-IE browsers, and in IE8, the div is positioning itself relative to
> the top of the DocumenPage div.
>
> Do you have any idea why?

It looks like IE <7 is getting margin-collapsing wrong.

> Although I've solved the problem using the
> above conditional comment, any light you can shed on this would almost
> certainly greatly me in the future when encountering (or better
> still anticipating) similar weird behaviour in the future.
>
> One clue that may in your investigation: there is a div in those
> mock-ups called "ScrollableContent", which has no assigned properties
> (because its purpose is to be used by an alternative stylesheet, and
> not by this one). Despite the fact that this div has no assigned
> properties, if I delete it, then all non-IE browsers start to behave
> like IE, in the sense that they position the TopOfPageIcons div
> relative to the top of the page, and I then have to define
> div.TopOfPageIcons to have top: 76px in all browsers. I don't
> understand why an undefined div can make such a big difference?

This is an important clue.

ScrollableContent's top margin collapses with the top margin of
DocumentPage. That means that even though ScrollableContent doesn't have
a top margin set on it, its top edge is 83px lower than it would
otherwise be.

TopOfPageIcons are the first thing inside ScrollableContent and
therefore positioned relative to its top edge.

But if you remove ScrollableContent, then TopOfPageIcons is right inside
body after the menu.

If you put padding-top: 1px on ScrollableContent then you will see the
same effect-- TopOfPageIcons will need to be top: 75px to put it back
where it was.

> But as
> I say, the ScrollableContent div needs to be there, because it's
> defined in an alternative stylesheet.

You could give it padding-top: 1px. Then you possibly won't need the
conditional comment for IE <7

Margin-collapsing is quite tricky which is probably why IE6 gets it
wrong.

If you have a situation like this:

<div style="background-color: green; height: 100px">
<div style="background-color: blue; height: 90px; margin-top: 100px">
</div>
</div>

the top edges of the green and blue divs should end up in the same
place, each with 100px of margin above them. So the child div moves its
parent down. This is what's happening on your page.

But if you put top padding or border on the outer div, that stops the
collapse happening since the two top margins are no longer adjacent but
separated by the padding or border.

It's difficult to explain why without just telling you to read the spec,
but the point is mainly that margin sort of means "gap until the next
solid edge", where a solid edge is a border or padding. If margins
weren't collapsed, then in the example above there'd be a 200px between
the top of the blue div and anything solid, which would be too much.

The bottom margin of a <p> collapsing with the top margin of the <p>
below it is fairly intuitive. A top margin collapsing against a
descendent top margin less so and does sometimes catch people out but
the spec is explicit that this is what's meant to happen.

31/03/2008, 01h14	#4
Ben C Messages: n/a Hébergeur:	Re: IE compatible way of forcing footer to bottom of page? On 2008-03-30, Dave Rado <dave.rado@dsl.pipex.com> wrote: [...] > I've succeeding in getting my footer to stay at the bottom of the > viewport if the height of the webpage's content's is less than the > height of the viewport; and in staying at the bottom of the webpage if > the height of the webpage's content's exceeds the viewport's height; > by using the method I linked to earlier. See my mock-ups at > http://tinyurl.com/2urjf2 (short content) and at http://tinyurl.com/393k5n > (long content). However, in order to get the three icons above my > "document page" to appear in the correct place in all browsers, I had > to add the following IE conditional comment: > ><!--[if lte IE 7]> > <style type="text/css"> > div.TopOfPageIcons {top: 76px} > </style> ><![endif]--> > > (As opposed to a top value of -8px that is required in all non-IE > browsers and in IE8 beta, according browsershots.org). > > That is, in IE7 and below (but not in IE8), the TopOfPageIcons div is > positioning itself relative to the top of the webpage; whereas in all > non-IE browsers, and in IE8, the div is positioning itself relative to > the top of the DocumenPage div. > > Do you have any idea why? It looks like IE <7 is getting margin-collapsing wrong. > Although I've solved the problem using the > above conditional comment, any light you can shed on this would almost > certainly greatly me in the future when encountering (or better > still anticipating) similar weird behaviour in the future. > > One clue that may in your investigation: there is a div in those > mock-ups called "ScrollableContent", which has no assigned properties > (because its purpose is to be used by an alternative stylesheet, and > not by this one). Despite the fact that this div has no assigned > properties, if I delete it, then all non-IE browsers start to behave > like IE, in the sense that they position the TopOfPageIcons div > relative to the top of the page, and I then have to define > div.TopOfPageIcons to have top: 76px in all browsers. I don't > understand why an undefined div can make such a big difference? This is an important clue. ScrollableContent's top margin collapses with the top margin of DocumentPage. That means that even though ScrollableContent doesn't have a top margin set on it, its top edge is 83px lower than it would otherwise be. TopOfPageIcons are the first thing inside ScrollableContent and therefore positioned relative to its top edge. But if you remove ScrollableContent, then TopOfPageIcons is right inside body after the menu. If you put padding-top: 1px on ScrollableContent then you will see the same effect-- TopOfPageIcons will need to be top: 75px to put it back where it was. > But as > I say, the ScrollableContent div needs to be there, because it's > defined in an alternative stylesheet. You could give it padding-top: 1px. Then you possibly won't need the conditional comment for IE <7 Margin-collapsing is quite tricky which is probably why IE6 gets it wrong. If you have a situation like this: <div style="background-color: green; height: 100px"> <div style="background-color: blue; height: 90px; margin-top: 100px"> </div> </div> the top edges of the green and blue divs should end up in the same place, each with 100px of margin above them. So the child div moves its parent down. This is what's happening on your page. But if you put top padding or border on the outer div, that stops the collapse happening since the two top margins are no longer adjacent but separated by the padding or border. It's difficult to explain why without just telling you to read the spec, but the point is mainly that margin sort of means "gap until the next solid edge", where a solid edge is a border or padding. If margins weren't collapsed, then in the example above there'd be a 200px between the top of the blue div and anything solid, which would be too much. The bottom margin of a <p> collapsing with the top margin of the <p> below it is fairly intuitive. A top margin collapsing against a descendent top margin less so and does sometimes catch people out but the spec is explicit that this is what's meant to happen.