I'm making a Wordpress theme with PHP, HTML and CSS.
My footer automatically floats down under the white content block when more text is added.
Now, I want to add another image that has to overlap the footer and also the white content block.
But... I want it to float down when more text is added, like the footer does.
Here's the link to make my question clear:
website
So, I want the image with the papers and the pencil to overlap both of the div's footer and the white content block. And it also needs to float down when more text is added.
oh, and I'm also having an issue with the outer edges of my footer, as you can see there is space, but the footer has to be full screen at the width.
-Thanks
Since the footer already aligns and "floats" as the content changes, the simplest solution would be to take advantage of this and place it inside the footer. From there you can position it partially outside with absolute positioning on the illustration and relative positioning on the footer.
Here's a proof of concept: http://jsfiddle.net/eliland/Qp76P/
Before going into the answers, I advise you to do 2 things:
validate your CSS, because from a very fast overview I spotted a typo at line 25 min-heigt which must be min-height
use CSS resets before any custome CSS. For this, check http://meyerweb.com/eric/tools/css/reset/
Personally I use normalize.css from http://necolas.github.com/normalize.css/
One more thing, and this is my opinion: there are plenty of cleaner themes out there which you can use to build your child theme. They include the latest in modern Web techniques, SEO, etc. E.g. Thematic, twentytwelve, twentyeleven, etc. And for free ...
Related
I'm trying to use a sticky footer, but it seems to having a conflict with my css, I'm following this tutorial, but I want to know why the footer is in the middle of the page, what do I have to do to fix it.
My code:
jsfiddle.net/q2Vuq/
The reason why you're seeing this strange behaviour with the sticky footer is because of your usage of position:absolute; on a number of your elements. Namely, the ones wrapped within the #navigation div.
Take a look at this (this JSFiddle just illustrates the problem more clearly):
I've given the offending elements all a background colour (as well as the body), so you can see that these elements are actually causing the scroll bar to extend beyond the height of the body. Absolute positioning actually takes them outside of the layout - meaning they don't cause their parent #navigation to expand, which in turn does not cause its parent .page-wrap to expand, which ultimately results in the footer not getting moved down. The footer gets put to the bottom of the body (as a result of the sticky footer CSS), which isn't quite low enough since the absolute-positioned elements extend even further below (as they are ignored by the body).
So, with that in mind, how do you fix this behaviour? Unfortunately, your sticky footer relies largely on the assumption that all content will be figured into the layout above it, or at least that the wrapper element above it will be tall enough to account for all its contents. This makes your use of absolute positioning hard to keep.
The best solution is probably to remove your current usage of absolute-positioned elements in your document, and rework how you're going to place your elements. Since I don't know what design you're actually aiming for, I can't provide an example of this. An alternative is to place an internal wrapper element inside of .page-wrap, with a min-height set such that it goes below even the lowest absolute-positioned element. However, this second method isn't too flexible, and I wouldn't recommend it.
If this isn't what you were looking for, or need more assistance in this particular matter, let me know and I'll be happy to help further. Good luck!
I'm using css sticky footer from http://www.cssstickyfooter.com/
Why do we need: #main{overflow:auto;} and #footer{position: relative;}?
Seems like it works without it (I'm not talking about Opera and IE fixes).
overflow:auto; will simply add the scroll bar if the page is longer than what can be displayed based on your screen height. I've used it before and believe it ensures your footer stays visible at the bottom of the page when you scroll.
Have you tried it on a page that is longer than the screen can display to see how it behaves?
Quote from cssstickyfooter.com:
No Need for Clearfix Hack!
Many CSS designers will be familiar with the Clearfix Hack. It solved
a lot of problems with floating elements. A previous version of this
Sticky Footer solution used it. Instead, a more modern and easier to
code solution is the overflow statement. We apply it to the main
to help get the footer to stick in Chrome. It also solves issues that
come up when using a 2-column layout where you float your content to
one side and your sidebar to the other. The floating content elements
inside the main can cause the footer to become un-stuck in some
browsers.
You might not need it but if needed overflow:auto makes an element act as a container that expands itself to contain it's floating elements (if any exists).
If you use firebug you can see what I mean by using it with overflow and click on the container element#main. It will stretch over the containing elements.
Without it the container element stays as small as possible and doesn't "contain" the other elements.
Read more here:
http://www.quirksmode.org/css/clearing.html
I have been trying for 2 hours to get my footer to stay at the bottom.
I have been trying "Matthew James Taylors" technique, but no luck.
Anyone see what I am missing or doing wrong?
Here is a Live Example : http://glustik.com/essex/index.html
Any help would be GREAT!
I would attached the CSS Code with the { } but it always breaks for me.
I feel like the CSS to fix this will still be problematic, I would be tempted to rewrite the whole thing: HTML markup and CSS, otherwise I suspect there will be more trouble down the road.
Here are some things that are most likely giving you trouble:
Duplicate id values (as mentioned)
Unnecessary absolute positioning
Hard-coded height values on several divs
Unnecessary use of "clearfix" divs
Overuse of negative margins to compensate for padding on other elements (always problematic)
Minor but relevant: use of classes like floatRight, just as bad as using inline styles.
I think in general, instead of trying to control the positioning and height of everything - just let the normal content flow dictate it. Naturally, the last element in your markup (footer) should be on the bottom without all these over-thought restrictions.
Best of luck!
EDIT: Apparently I've come off as unhelpful, so I felt I should add a direct response: For a quick fix, to simply get the footer on the bottom:
Remove the height and bottom padding from #mainBody
(tested in FF4 and IE8). There will still be some padding issues within the footer, but that can be resolved in a number of ways depending on how you'd like to approach it. Once again, good luck with your project.
You have the footer positioned absolutely in #container, which is positioned relatively. therefore, its being positioned at the bottom of #container.
try moving it out of #container, or remove the relative positioning from #container
Because all of the content inside your main container (#mainBody) is floated, the container's only way to determine it's height is via the "height" property, which is set to 100px;. The footer is correctly rendering right below the 100 pixel height of the main container.
You have three options:
you can either properly clear your main container so that its height is dynamic based on its content using a clearfix like this
or you can set the height of the main container to something larger. I changed it to 700px and the footer rendered well below the main body.
or you can remove the height altogether, which will probably be the best solution in the long-run. Thanks to #Gaby aka G. Petrioli for pointing this out.
I've been doing this a long time and have never heard of this method. That doesn't make it bad, but the currently accepted version in my circles comes from Ryan Fait (http://ryanfait.com/resources/footer-stick-to-bottom-of-page/)
If you load this up in Chrome and disable the position:relative from the container it does properly glue the footer to the bottom of the page. That signals a problem to me, because it's contrary to what the tutorial says. Regardless, it accomplishes your goal.
You should take at least a look at Compass. It makes CSS so much easier. For your particular question, take a look at:
http://compass-style.org/reference/compass/layout/sticky_footer/
Make the following changes and it rendered fine in Chrome for me:
remove bottom:0; from #footer
change padding-bottom:167px; in #mainBody to the desired location (I used 455px and it looked pretty good)
Alright, so this is basically the usual "how to vertically center with CSS" question, but with some catches.
No Javascript. HTML and CSS only. CSS3 is fine as long as it's reasonably well supported by today's browsers.
The element's content, and therefore height, is not known. It may be anywhere from a few dozen to a few hundred pixels. In the future I might even have a script adding and removing elements inside, so it may change height as the user is interacting with it.
There is other content on the page - a navigation bar at the left and a menu at the top. These need to be accessible.
The approach I've used is the three-container-div method using display: table-cell, as documented at: http://www.jakpsatweb.cz/css/css-vertical-center-solution.html this solves issues 1 and 2, but not 3.
http://imgh.us/vcenter.jpg shows the design and the problem. The yellow box is the innermost container. The red and green dotted boxes around the entire page (which have become somewhat blurred together due to JPEG encoding) are the outermost and middle containers respectively. (The out-of-place footer is a separate issue...)
The problem with this layout is the outer containers cover the entire page, and this makes it impossible to click on the navbar, because it's now "under" those containers. Z-index can move them to the bottom, but then it becomes impossible to click on anything inside the red box, because it's now "under" the page's main content box. (XHTML only allows a single element inside the <body>, so I've just wrapped it all in a <div>.) Even if the outer two containers have z-index: -100 and the inner container has z-index: 200, it still ends up under the main content box for some reason. (I did try various position attributes.)
The only solution I've seen is a new CSS3 property, pointer-events, that would in theory allow me to make events pass through the transparent containers as I'd expect; however this seems to be quite new and not yet supported by most browsers outside of SVG, and I imagine I'd have the same trouble as with Z-index.
I do want the element at the center of the page, not the center of the content area (i.e. ignoring navbars in the calculation of position), so placing the container inside the content area isn't an ideal solution. (I'm using this style on the login page as well, which has no navbars, and it'd look a bit strange if the "centered" elements were centered relative to a navbar that isn't always visible.)
In summary what I need is to center, without using Javascript, an element of unknown height on a page with other content at its edges, without covering any of the content with an invisible layer (and thus making it unclickable).
While this is obviously an old question and the OP has undoubtedly solved this problem, I figured I'd add a link to Chris Coyier's marvelous write-up on how to deal with this issue for future wayfarers in need of a similar solution.
http://css-tricks.com/centering-in-the-unknown/
I have noticed a common technique is to place a generic container div in the root of the body tag:
<html>
<head>
...
</head>
<body>
<div id="container">
...
</div>
</body>
</html>
Is there a valid reason for doing this? Why can't the CSS just reference the body tag?
The container div, and sometimes content div, are almost always used to allow for more sophisticated CSS styling. The body tag is special in some ways. Browsers don't treat it like a normal div; its position and dimensions are tied to the browser window.
But a container div is just a div and you can style it with margins and borders. You can give it a fixed width, and you can center it with margin-left: auto; margin-right: auto.
Plus, content, like a copyright notice for example, can go on the outside of the container div, but it can't go on the outside of the body, allowing for content on the outside of a border.
This method allows you to have more flexibility of styling your entire content. Effectively creating two containers that you can style. The HTML body tag which serves as your background, and the div with an id of the container which contains your content.
This then allows you to position your content within the page, while styling a background or other effects without issue. Think of it as a "Frame" for the content.
I faced this issue myself redesigning a website. Troy Dalmasso got me thinking. He makes a good point. So, I started to see if I could get it working without a container div.
I could when I set the width of the body. In my case to 960 pixels.
This is the CSS I use:
html {
text-align: center;
}
body {
margin: 0 auto;
width: 960px;
}
This nicely centers the inline-blocks which also have a fixed width.
The most common reasons for me are so that:
The layout can have a fixed width (yes, I know, I do a lot of work for designers who love fixed widths), and
So the layout can be centered by applying text-align: center to the body and then margin: auto to the left and right of the container div.
Certain browsers (<cough> Internet Explorer) don't support certain properties on the body, notably width and max-width.
This is one of the biggest bad habits perpetrated by front end coders.
All the previous answers are wrong. The body does take a width, margins, borders, etc. and should act as your initial container. The html element should act as your background "canvas" as it was intended. In dozens of sites I've done I've only had to use a container div once.
I'd be willing to be that these same coders using container divs are also littering their markup with divs inside of divs--everywhere else.
Don’t do it. Use divs sparingly and aim for lean markup.
I later found this, years after my answer, and see that there are some follow up replies. And, surely you jest?
The installed placeholder site you found for my domain, which I never claimed was my markup or styling, or even mentioned in my post, was very clearly a basic CMS install with not one word of content (it said as much on the homepage). That was not my markup and styling. That was the Silverstripe default template. And I take no credit for it. It is, though, perhaps one of only two examples I can think of that would necessitate a container div.
Example 1: A generic template designed to accommodate unknowns. In this case you were seeing a default CMS template that had divs inside of divs inside of divs.
The horror.
Example 2: A three column layout to get the footer to clear properly (I think this was probably the scenario I had that needed a container div, hard to remember because that was years ago.)
I did build (not even finished yet) a theme for my domain and started loading content. For this easily achieved example of semantic markup, click the link.
http://www.bitbeyond.com
Frankly, I'm baffled that people think you actually need a container div and start with one before ever even trying just a body. The body, as I heard it explained once by one of the original authors of the CSS spec, was intended as the "initial container".
Markup should be added as needed, not because that’s just the way you've seen it done.
div tags are used to style the webpage so that it look visually appealing for the users or audience of the website. Using container-div in HTML will make the website look more professional and attractive and therefore more people will want to explore your page.
Well, the container div is very good to have, because if you want the site centered, you just can't do it just with body or html...
But you can, with divs. Why container? It’s usually used, just because the code itself has to be clean and readable. So that is the container... It contains all of the website, in case you want to mess around with it :)
Forget the container. It's just a habit from the old, very old days.
Everything you can do using a div—you can also do it on a body tag.
I've never heard of issues using a div class="container" markup. But I have heard of issues using body as a top level container. See this article. Stick with the tried and true; who knows what browsers will do in the future.
Most of the browsers are taking the web page size by default.
So, sometimes the page will not display same in different browser. So, by using <div></div>, the user can change for a specific HTML element. For example, the user can add margin, size, width, height, etc. of a specific HTML tag.