[css-d] Safari miscalculating bottom for absolute positioning
I'm not a Mac user, so I'm not skilled at debugging problems in Safari
and am wondering if some of the Mac CSS gurus can help me. I have a
footer div, relatively positioned, that contains two anchor elements
which are absolutely positioned to appear on its bottom. This works
everywhere except Safari. Safari adds a great deal of space below the
footer and positions the anchors at the bottom of the page.
The space is not filled with the background color of the footer div, so
I know Safari is not extending the height of the footer div.
Also, if I change the bottom value to a top value, the anchors do sit at
the top of the footer, so I know it is not a case of them not
recognizing that they ought to be positioned in regards to the footer
div and not the body.
If I change the font size, the gap between the bottom of the footer and
the anchors widens or contracts accordingly. I'm not sure what this
means, but it's another clue, perhaps.
The bug occurs on every page of this site:
http://www.hsrc.unc.edu
Here's the CSS for the footer and its child elements.
#footer {
position: relative;
clear: both;
padding-top: 1px;
background: #e1eef0 url(../images/footer_bg.jpg) repeat-x;
font-size: 90%;
}
#footer p {
margin: 0;
margin-top: -8px;
padding: 20px 80px 10px 58px;
background: url(../images/footer_swoosh.gif) no-repeat;
}
#contact-btn {
position: absolute;
bottom: 0;
right: 75px;
width: 70px;
}
#sitemap-btn {
position: absolute;
bottom: 0;
right: 10px;
width: 57px;
}
As I said, I'm not an experienced Safari debugger, so I'm not sure what
I should even try in order to squash this bug. The only thing I tried
was giving the 0 values a unit, 0px, but that didn't work. I don't have
any other ideas.
Thanks,
Zoe
--
Zoe M. Gillenwater
Design Services Manager
UNC Highway Safety Research Center
http://www.hsrc.unc.edu
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Safari miscalculating bottom for absolute positioning
Zoe,
the problem seems to be related to #project-areas and #latest-news.
Remove those two blocks and the problem goes away. As do the two
blocks. Of the two blocks it's #project-areas which is doing the most
damage. Try setting #project-areas p and #project-areas ul to
display: none to see what I mean.
I guess this is to do with fact that Safari somehow remembers the
height of the body element based on the dimensions of the elements
present at load time. I've seen this kind of thing happen when
removing elements with javascript and the same sort of thing seems to
be happening because of the absolutely positioned elements. I hadn't
seen this exact behaviour of yours before, but it certainly looks
like Safari is hanging on to its notion of where #footer starts
out...
The good news is that the nightly builds of WebKit do not display
this behaviour.
The way I work around this sort of thing at the moment is to target Safari
http://tanreisoftware.com/blog/?p=39#safari
so that the offending blocks are hidden and add a class onload so
that they get shown again. Not pretty, but the best I've been able to
come up with so far
http://www.fu2k.org/alex/css/cssjunk/hsrc
html[xmlns*=] body:last-child #project-areas, html[xmlns*=]
body:last-child #latest-news { display: none; }
html[xmlns*=] body.enabled:last-child #project-areas,
html[xmlns*=] body.enabled:last-child #latest-news { display: block;
Alternatively, put the button links inside a div (or similar) and
position those. Safari doesn't seem to get things quite so badly
wrong then.
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Safari miscalculating bottom for absolute positioning
Alex Robinson wrote:
the problem seems to be related to #project-areas and #latest-news.
Remove those two blocks and the problem goes away. As do the two
blocks. Of the two blocks it's #project-areas which is doing the most
damage. Try setting #project-areas p and #project-areas ul to display:
none to see what I mean.
I guess this is to do with fact that Safari somehow remembers the
height of the body element based on the dimensions of the elements
present at load time. I've seen this kind of thing happen when
removing elements with javascript and the same sort of thing seems to
be happening because of the absolutely positioned elements. I hadn't
seen this exact behaviour of yours before, but it certainly looks like
Safari is hanging on to its notion of where #footer starts out...
Ah yes, that makes sense. It's probably due to the negative margin
technique this site uses that pulls the sidebar up into a hole (because
not just the home page displays it, and the other pages don't have those
two divs you mentioned).
The good news is that the nightly builds of WebKit do not display this
behaviour.
That is good. How often do updates to Safari come out?
The way I work around this sort of thing at the moment is to target
Safari
http://tanreisoftware.com/blog/?p=39#safari
so that the offending blocks are hidden and add a class onload so that
they get shown again. Not pretty, but the best I've been able to come
up with so far
http://www.fu2k.org/alex/css/cssjunk/hsrc
html[xmlns*=] body:last-child #project-areas, html[xmlns*=]
body:last-child #latest-news { display: none; }
html[xmlns*=] body.enabled:last-child #project-areas,
html[xmlns*=] body.enabled:last-child #latest-news { display: block;
Thanks. I'll consider doing this.
Alternatively, put the button links inside a div (or similar) and
position those. Safari doesn't seem to get things quite so badly wrong
then.
Yeah, I thought about doing this as well, but I hate mucking up the HTML
just to kill a bug that will go away soon. I'll take another look at it,
and my logs, and decide if it's really worth it to do anything or just
live with it.
Thanks,
Zoe
--
Zoe M. Gillenwater
Design Services Manager
UNC Highway Safety Research Center
http://www.hsrc.unc.edu
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
