Hi

When the height of the content of a webpage is less than the height of
the viewport, I would like to force the footer to the bottom of the
viewport; whereas when the height of the content of the webpage
exceeds the height of the viewport, then I would like the footer to be
at the bottom of the webpage (so not visible until you scroll down to
it).

I tried using the method described at http://tinyurl.com/2upa7l but it
doesn't work in IE6 or in IE5.5 (although it does work in IE7) - see
my mock-ups at http://tinyurl.com/2urjf2 (short content) and
http://tinyurl.com/393k5n (long content).

My problem is that (unfortunately) around 32% of users are still using
IE5.5 or IE6 (see http://tinyurl.com/56kp), and I therefore expect a
large percentage of the visitors to my site to be IE 5.5 and 6 users.

Is there any cross-browser-compatible way of achieving the above
objective?

Dave

I've found the answer - the solution is described at http://tinyurl.com/a8u5w
.. It is almost identical to the method I was using but it includes the
following addtional line:

* html #nonFooter {height: 100%;}

With the addtion of this line, it works in all browsers including
IE5.5. I don't understand why it works though - does anyone understand
the significance of the asterix? And of what the difference is between
#nonFooter and * html #nonFooter?

Dave

Hi dorayme

On 30 Mar, 02:19, dorayme <doraymeRidT...@optusnet.com.au> wrote:

> The asterisk in css is a universal selector and unless it
> is over-ruled later in the style sheet will have all elements following
> its dictates. Thus, to look at a common example, * {margin: 0; padding:
> 0;} causes all margins and paddings to be set to zero.[1]

Thanks, that's useful to know.


> The asterisk before the html element is an interesting case and it is
> used to take advantage of what has appeared to almost everyone (except
> me to a certain extent[2]) as a bad misconception of Internet Explorer
> prior to version 7. Because IE is the only truly religious browser it
> alone recognises an element higher than the html element, and so it
> takes note of the style concerned. Whereas other more atheistic browsers
> ignore such babble. This enables authors to talk to IE and tell it to do
> things that will not bugger up the other heathen browsers.

LOL!

So is it okay for me to use * html in order to specify "applies only
to IE6 and below"? I read somewhere that it's unsafe to use because
although it validates, it's invalid, and future standards-compliant
browsers could conceivably stop ignoring it. What do you think? It
does have the huge advantage over IE conditional comments of being
usable within an external css file, so one doesn't need to import so
many css files if one uses it as one does if one uses conditional
comments. And if this hack is okay to use, in your opinion, are there
any other similar hacks that also are okay to use?


> 2. Because of my very deep studies into the mysteries of the html
> element and beyond, I have caught glimpses of the Beyond that IE6 (and
> lower) instinctively know about. In my case, I have had work hard in a
> field that is unnatural to me. I wear a special black cape and a sort of
> wizard's hat in my pursuit of what I am calling Root Studies.

In that case I hope you'll be willing to shed some light on some more
weird IE behaviour that I've just encountered (please don your cape
and wizard's hat before reading on. I could also lend you a broomstick
if you think that would ).

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? 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? But as
I say, the ScrollableContent div needs to be there, because it's
defined in an alternative stylesheet.

Happy sleuthing!

Dave

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.

Hi Ben

On 31 Mar, 00:14, Ben C <spams...@spam.eggs> wrote:

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

Actually IE <=7 - the first Microsoft Browser to get it right is IE8
beta.

> > One clue that may in your investigation: there is a div in those
> > mock-ups called "ScrollableContent

> 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.

[....]

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

That fixed the problem, many thanks, Ben! I'm glad not to have to have
to import and maintain yet another conditional stylesheet (especially
as I don't know of a safe hack that one can embed in an external
stylesheet equivalent to <=IE&.


> Margin-collapsing is quite tricky which is probably why IE6 [actually IE7 and below] 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.


That's a very ful explanation, thanks. I found it even more
revealing to experiment with:

<body style="padding: 0; margin-top: 0">

<div style="background-color: blue; min-height: 50px">
<div style="border: 2px solid black; height: 100px; margin-
top: 100px">
</div>
</div>

</body>

And to then remove and replace the inner div, and to add 1px padding
to the outer div.


> It's difficult to explain why without just telling you to read the spec

Reading the spec doesn't someone like me to understand its subtle
implications. Extrapolating from the box model diagram to some of its
less intuitive implications is something you're far better at than me,
partly, I suspect because of your much greater real world experience
with using it, and partly because we have different talents.

I'm still confused about some aspects of this. If you look at the last
mock-up I posted in the previous thread you ed me with ("Is it
possible to vertical align in a div?", and the mock-up at
http://tinyurl.com/2otuph), in that mock-up there is no div above the
TopOfPageIcons one, and the TopOfPageIcons one is self-contained, it
isn't a wrapper div like the ScrollableContent one; so I would have
expected it to be positioned relative to the top of the page, but it
isn't, it's positioned relative to the DocumentPage div. Can you shed
any light on this?

Dave

Hi dorayme

On 31 Mar, 02:41, dorayme <doraymeRidT...@optusnet.com.au> wrote:

> I find it easy enough to add an IE sheet and conditionally link it in
> the head of the html.

My problem is that I'm finding some conditional css definitions are
needed just for IE5.5, others for IE6 and below, and still others for
IE7 and below, which means a potential requirement for up to three
conditional stylesheets (although Ben has just ed me get rid of
the "IE7 and below" one, unless I encounter another bug that applies
to IE 7 and below).

I'm already using a conditional stylesheet for IE5-specific styles,
but I do like the idea of using the * html hack to obviate the need to
have an "IE6 and below" conditional stylesheet as well; and it would
also be nice if there were a safe and reliable "IE7 and below" hack as
well, in case I find another bug that applies to IE7 and below but not
to IE8 beta.

I take your point about conditionals within the html body being very
useful at times.

Dave

On 2008-03-31, Dave Rado <dave.rado@dsl.pipex.com> wrote:
[...]
> I'm still confused about some aspects of this. If you look at the last
> mock-up I posted in the previous thread you ed me with ("Is it
> possible to vertical align in a div?", and the mock-up at
> http://tinyurl.com/2otuph)

That URL expands to
http://localhost/swindle/Dev/Mockups...lativeProb.htm

Hi Ben

On 1 Apr, 19:39, Ben C <spams...@spam.eggs> wrote:
> That URL expands tohttp://localhost/swindle/Dev/Mockups/PosNotRelativeProb.htm

Whoops, sorry, I meant http://tinyurl.com/2j68p3 .

To save you looking up my previous post again, it should have read:

I'm still confused about some aspects of this. If you look at the last
mock-up I posted in the previous thread you ed me with ("Is it
possible to vertical align in a div?", and the mock-up at
http://tinyurl.com/2j68p3), in that mock-up there is no div above the
TopOfPageIcons one, and the TopOfPageIcons one is self-contained, it
isn't a wrapper div like the ScrollableContent one; so I would have
expected it to be positioned relative to the top of the page, but it
isn't, it's positioned relative to the DocumentPage div. Can you shed
any light on this?

***

Apologies again.

Dave

On 2008-04-01, Dave Rado <dave.rado@dsl.pipex.com> wrote:
> Hi Ben
>
> On 1 Apr, 19:39, Ben C <spams...@spam.eggs> wrote:
>> That URL expands tohttp://localhost/swindle/Dev/Mockups/PosNotRelativeProb.htm
>
> Whoops, sorry, I meant http://tinyurl.com/2j68p3 .
>
> To save you looking up my previous post again, it should have read:
>
> I'm still confused about some aspects of this. If you look at the last
> mock-up I posted in the previous thread you ed me with ("Is it
> possible to vertical align in a div?", and the mock-up at
> http://tinyurl.com/2j68p3), in that mock-up there is no div above the
> TopOfPageIcons one, and the TopOfPageIcons one is self-contained, it
> isn't a wrapper div like the ScrollableContent one; so I would have
> expected it to be positioned relative to the top of the page, but it
> isn't, it's positioned relative to the DocumentPage div. Can you shed
> any light on this?

This is quite a tricky one. TopOfPageIcons has zero height, and no
borders or padding (the only thing in it is the absolutely positioned
images, and they don't give it any height).

That means that margins collapse _through_ it. The complete set of
margins that collapse here are: body's top margin (0), the top and
bottom margins of TopOfPageIcons (both 0), and the top margin of
DocumentPage (83px).

That lot results in <body> getting a resultant top margin of 83px (which
you can't see because for reasons discussed elsewhere, body's background
colour ends up on the canvas instead). This is what puts TopOfPageIcons
83px from the top.

If you add height: 1px to the styles for TopOfPageIcons it prevents
margins collapsing through it, and so your icons move right up to the
top of the page.

CSS 2.1 8.3.1:

If the top and bottom margins of a box are adjoining, then it is
possible for margins to collapse through it. In this case, the
position of the element depends on its relationship with the other
elements whose margins are being collapsed. If the element's margins
are collapsed with its parent's top margin, the top border edge of
the box is defined to be the same as the parent's.

I doubt all browsers will get this right, although I think Firefox is.
But this was just one of your intermediate versions I think anyway?

On 1 Apr, 22:27, Ben C <spams...@spam.eggs> wrote:


> This is quite a tricky one. TopOfPageIcons has zero height, and no
> borders or padding (the only thing in it is the absolutely positioned
> images, and they don't give it any height).
>
> That means that margins collapse _through_ it. The complete set of
> margins that collapse here are: body's top margin (0), the top and
> bottom margins of TopOfPageIcons (both 0), and the top margin of
> DocumentPage (83px).
>
> That lot results in <body> getting a resultant top margin of 83px (which
> you can't see because for reasons discussed elsewhere, body's background
> colour ends up on the canvas instead). This is what puts TopOfPageIcons
> 83px from the top.

Thanks, that makes sense. It's very complicated to work out all the
permutations though!


> But this was just one of your intermediate versions I think anyway?

Yes I'm not using that version now, but just wanted to illustrate why
I was still confused about the principles you'd explained earlier.

Thanks again.

Dave