When you hover over the top nav links (contact/donate/media) in IE7, the footer div comes up to the level of the sidebar.
I've tried:
- Disabling all scripts
- Putting clear divs in footer
- Setting height/min-height for the sidebar.
- Removing the twitter/facebook widgets
- Removing all the CSS stylings for the top navigation bar
Same problem. Any ideas?
I have had a problem similar to this a few years ago. What caused it for me:
hovering over a link in a menu
menu item changes size ever-so-slightly by adding a 1px border, creating an underline, becoming italicized, etc..
new size of item caused the outside container to become a few pixels wider than the declared width
footer/other content floats up because there are a few extra pixels OR
something on the same height of the menu is kicked down a below the container-object and throws a wrench in the rest of the flow
Hope my experience helps!
edit
Yes, I did fix it.. It was a mess, but basically involved going through each :hover selector and making sure that absolutely nothing changed -- except the colors involved. I also remember that I needed to re-declare and width: nnpx; height: nnpx; in the :hover selector.
Man! Love programming for old browsers!
Solution was to move the "navigation" div inside the "header" div.
Don't know why, just kept taking out divs by process of elimination.
Related
I've got this weird problem which it seems that i simply can't solve (so far). The weird thing is that I've done almost exactly the same layout before for a navigation-bar, which was succesful.
In my navigation bar i have a button (not an actual <button> but a <div> which acts like one through jquery) to the farthest right of it, which has a background color and expands on click. The problem is that in IE and some resolutions of Chrome as well, there's a little white stripe shown beneath this div. Further this makes the child div that expands beneath it have a little gap between the button in the navigation bar and it self. This might not matter to some people (or most), but it's driving me mad - especially considering that i've done it before and used almost the very same css.
The <div> (to be more precise, it's the "quick-download" div) is set to a height of 70px and line-height of 70px, and the same goes for its siblings (and some of them less). However, the parent div shows up as 70.4px in height, which is bugging me out. I've tried numerous "trial-and-error" solutions/attempts, but with no success at all.
EDIT:
An image of the problem can be seen here (i changed background to red to make it more apparent): http://imgur.com/fya0duQ
EDIT 2:
The white space beneath the quick-download div appears only to be showing in IE and Safari on my compute right now.
EDIT 3:
Link to website is removed as the problem is corrected and therefore no longer is useful.
Assuming you mean the "Quick Download" button...
The height of the navigation bar is 75px and the height of the button is 70px, creating a 5px-tall gap.
The reason your navigation bar is 75px is because your image on the left is 60px tall with margin-top: 15px;. If you want the button to be flush with the bottom of the navigation bar, you can either increase the height of the button, reduce the margin-top of the <img id="aktie-skat-logo" ...>, or reduce the image's height.
The CSS in question:
#aktie-skat-logo {
margin-top: 15px;
display: block;
}
I've actually tracked the problem down my self - however, only after checking the problem across different browsers, after posting in here. The hint came in my old version of safari and IE, and didn't show in Chrome - which is consistent with "EDIT 2" in the original post. I found that some links we're 0.4px higher than others, but only 2/5 links.
The problem apparently stems from inserting a FontAwesome icon using the css ::after selector to links that has "children" (subpages). After removing this or making these icons position:absolute the problem is solved.
As to why insering these using ::after I have no idea. The ::after element had display:inline so shouldn't have broken too much in my opinion.
I'm sorry that I might have wasted your time checking my problem and answering, but even though I found the solution my self, it was a help posting in here (wouldn't have found it otherwise). I hope this might help some other people at some point.
This website is built with a back-end web to print service called Zoo Printing. The client I work for does not like the original design so I've being hired to re-design it with the development team that handles the back-end. I replaced their old navigation menu with the current CSS mega navigation that's on the site. Their developers decided to keep their code on the website for back up just in case they need to roll-back to the old navigation. The issue is even though their code is commented out, it creates a huge white space between my CSS slideshow and footer. Their developers are blaming my code and will not tell me where the problem is coming from. Can one of you inspect my code and tell me what would be causing this? I've tried simply removing the white space with CSS by absolute positioning it off the page, but when i do this the footer changes on every page except the home and it also removes my CSS slide show. I can not figure out how to remove this white space without messing with my layout.
The website is Advanced Litho
body > div:nth-child(4)
This is the div that's creating the issues with the layout. So far I've tried to absolute position it off the page with no luck.
There is a div at the bottom that is making the space huge, it is right above the commented out content and right below the div with id=content. All of these boxes have a visibility of hidden which does not delete them from your page, it simply makes them invisible. All you need to do is find that div, and insert an inline style.
<div style="display: none;">(old nav)</div>
Essentially, they just hid what they were supposed to remove.
There are unordered lists inside <div class="nav_child"></div>
If you can remove them, it is best to do so, otherwise you can hide them with css and get rid of the white space:
.nav_child ul {
display: none;
}
I am designing a site for a new foundation, and I have set April 15 as my deadline for finishing it. It is ready except for editing the content and fine-tuning the design. In the fine-tuning, I am wrestling with an irksome little problem that I would like to ask someone to please help me solve. The problem is simply this: a division in the site's structure will not function as I would like for it to function unless it has a border around it. Never seen a thing so erratic before.
The problem appears to be related to how the elements interact in the layout. First, there is the html tag which holds the background image, a jpeg of a creek with some buildings on the far side and a green grove of grass created by a divisional tag (#greengrass) positioned at the bottom of the background image . div#greengrass is styled to extend downward as a content div, resting on top of it, lengthens. It is this #greengrass element that performs awkwardly unless there is a border laced around it.
Specifically, if its border is removed, it projects upward and covers the background image, even though positioned to start where the background image ends. Its upward projection, therefore, makes the entire page background green. But when it has a border, the background image of the creek shines through as bright as the sunny spring sun.
Thus, I have one question: Why does the absence or presence of the division's border affect its behavior? Here is the url to the test site for the foundation: http://postmaterial.org/tests/signin-ap.php. At top center, I've added a link that lets you toggle between the bordered and borderless div#greengrass effects. I have no clue as to the reason for the tag's behavior and would appreciate an explanation. Thanks.
To answer your question: "Why does the absence or presence of the division's border affect its behavior?" I agree with ichao (as his answer stated) that collapsing margins is the issue.
However, I think the solution is to keep only a border-top: 1px solid #009900 as it is only the top border that is needed to prevent the margin collapse. This will prevent the horizontal scroll bar from showing up.
without the border of #greengrass, the negative margin-top of its child collapses through (and pulls the entire construct out of sight, topwards), and in consequence, #greengrass is not pushed down enough by top anymore.
border prevents collapsing margins, as display:inline-block or display:table or float:left would in this case (overflow:hidden is not an option here). In old IE, any haslayout trigger like zoom:1 should do. I did not test it, though.
Been struggling with this for at least a couple hours now. Tried searching around but no solution seems to be working. So anyways, I have a template that I'm working on, and the issue that I'm having is that the sidebar on the left just will not stretch all the way down! If the window is maximized, it looks totally fine. Once you resize the window though it breaks, leaving a large gap between the sidebar and the footer. It also breaks if the content goes down the page any more than it currently does...
See for yourself here: http://bakedcraft.ca/laboratory/testsites/crock/template.html
and the css: http://bakedcraft.ca/laboratory/testsites/crock/css/default.css
Any ideas?
Add position:relative to your .main class
right now your side bar is 100% height of the window, not the main container. by adding position:relative to the sidebar's parent, when the sidebar is 100% height, it becomes 100% of the main div.
Sorry, this isn't really an answer but it's not letting me write a comment...
I looked at your code in firebug (firefox + web developer add-on) and it's showing a box constraint of 467px height I tried to quickly find where this 467px are coming from but can't see it with quick look (it's 4 AM). It's inheriting that height from somewhere, most likely from a combination of other size constraints of related elements. With all the positioning you have going on, in may be hard to locate.
One suggestion I have is if you plan on making a fluid layout you should work with em's rather than straight pixels. As I said, this isn't an answer but I did notice the size constraint of your sidebar. If this problem is still open in the morning I'll see if I can get a better look at it for you.
Alright I was running your problem through my head and I think I figured it out. Forgive me cuz I'm typing this on my phone and can't use firebug to verify if I'm right or not but the constraint I noticed earlier of 467px is n't inherited from another container it's being constained by the text in the sidebar div. If u were to add more text the box will grow with it. I believe what u may want to do is make a child conatiner within the side bar div. Your main sidebar div will only house your grey background color grey. Create a child div within the sidebar div and put your text and images into those. Make sure on the parent div you make it's height 100%. The height of the elements inside the child div shouldn't need height specifications since they will be inherited from the parent sidebar div. Hope this makes sense.
You can do the fix mentioned earlier with using jquery but remember if someone shuts of their JavaScript then your issue remains and your page will break. You should try to find and fix the root cause not use a bandaid that can be taken off.
In FF and IE8 things look pretty good. I have a mock up of the drop down that I'm trying to create with rounded corners at bottom here: www.geowinedb.org/drop-down-test/test.html. In IE6 the mega div is extending to the far left edge of the window. What do I need to change/add (e.g. underscore hacks) to get the drop-down to shrink-wrap its contents (the ul).
p.s. I'll be back to ask about the z-index problem that blocks the drop-down (IE6 again), but if anyone want to answer that as well it will be much appreciated.
EDIT 20091107: More specifics on the requirements: It must work in IE6+ and the drop down menus cannot be fixed width. The client wants to be able to change menu item text at will and have the drop-downs size automatically.
EDIT 20091111: I never did find a great solution. The menu along with some other requirements for hover changes, meant that JavaScript was necessary. So, I found that I could position each main menu item absolute, then position each sub-menu div absolute (this solved the z-index problem), and lastly I computed the width from the underlying ul and set the outer div width. Then the rounded corners positioned themselves correctly on all the browsers that I needed.
Does it bother to use fixed width for your UL (and maybe UL.mega-b too) ? because this way you will definitely avoid this problem.
display:block in your UL can also be the cause of this.