Anyone who is accustomed to fully-fledged pages of sites prefers the appearance of “nailed” (sticky) to the bottom of the page footer. But there are two troubles on the Internet: non-growing down input fields and non-beat (to the bottom of the window) footers. For example, when opening short-height pages like
habrahabr.ru/settings/social , it immediately catches the eye that the information intended to be in the lower part of the viewing window sticks to the content and is somewhere in the middle, or even in the upper part of the window when below is empty.
So,

instead of

.
This guide for beginner web designers will show how in 45 minutes to make a “nailed” footer, correcting the flaws of even such a respected publication as Habr, to fray with it as an execution of its promising project.
Let's look at the implementation of one type of nailed footer, taken from the network, and try to understand what is happening.
css-tricks.com/snippets/css/sticky-footer
CSS:
* { margin:0; padding:0; } html, body, #wrap { height: 100%; } body > #wrap {height: auto; min-height: 100%;} #main { padding-bottom: 150px; } #footer { position: relative; margin-top: -150px; height: 150px; clear:both;} .clearfix:after {content: "."; display: block; height: 0; clear: both; visibility: hidden;} .clearfix {display: inline-block;} * html .clearfix { height: 1%;} .clearfix {display: block;}
HTML:
<div id="wrap"> <div id="main" class="clearfix"> </div> </div> <div id="footer"> </div>
It is unlikely that everyone, even knowing CSS, looking at this code, will understand the principles and will confidently rule a complex project. Any step to the side will lead to side effects. The reasoning and making the footer below are meant to give more insight into the CSS rules.
Let's start with the theory
The usual implementation of a nailed footer is based on the property that is unique to CSS2, that elements - direct descendants of
BODY - support percentage height (
height: 100% or other) relative to the window, if all their parents also have percentage height, starting with an
HTML tag. Earlier, without doctypes, but now in Quirks Mode the percentage heights of the elements are maintained at any level, and in modern doctypes only inside the percentage of specified elements. Therefore, if we make a block of content (let's call it
#layout ), which has 100% height, it will scroll as if it were a window. They put all the (streaming) content in it, except for the footer and, maybe, the header.
')
The footer is placed after this block and makes it 0 pixels high. In general, you can put as many blocks as you like after
#layout , but all of them must be either with 0 pixels of height, or outside the document stream (not
position: static ). And there is another important trick that is commonly used. It is not necessary to make the height equal to 0. You can make the height fixed, but subtract it from the main unit using the
margin-bottom property
: - (height); .
Speaking in human language, styles make an empty “pocket” on the bottom, into which the footer is inserted, and it always turns out to be either stuck to the lower border of the window, or to the lower border of the document, if the document is higher than the height of the document.
On the Internet and on Habré there are many implementations of the footer, with varying success in all browsers. We will continue to build it yourself, using the layout Habra as a "workhorse".
Since the bottom of the
#layout block is a pocket, it must be empty for the footer, not displaying page objects. And here we meet with another limitation - we cannot make an empty pocket due to
padding in
#layout , because then it will become more than 100%. It will not save the
margin either - emptiness needs to be done due to the properties of the nested elements. Plus, it is necessary to ensure non-crawling under the border of a block of floating elements, which is done, for example, by block
<div class="clear"></div>
where
.clear {clear: both} . It is important that either this "
height " is fixed, or in the same relative units, or we would calculate it in the process of page changes. It is usually convenient to combine this leveling unit with the installation for it of the required height.
Let's look at the structure of our experimental pages. The easiest way to do this is to open a Firebug window or similar window (Developer Tools (Ctrl-F12)) in Chrome.
<!DOCTYPE html> <html xml:lang="ru" xmlns="http://www.w3.org/1999/xhtml"> <head> <body> <div id="topline">... ...</div> <div id="layout"> <div id="header"> <div class="content_left">...=== ===...</div> <div class="sidebar_right">... ...</div> <div class="clear"></div> <div class="rotated_posts">...</div> <div id="footer"> <dl class="user">..<dl> <dl>...<dl> <dl>...<dl> <dl>...<dl> <dl>...</dl> <div class="copyright">...</div> </div> </div> <div id="AutocompleteContainter_ea125"></div> <div class="token-input-dropdown-hubs"></div> <div id="tiptip_holder" style="max-width:300px;"> <div id="jGrowl" class="top-right jGrowl"> </body> </html>
Let's move on to the working example.
What are the
drawbacks of the layout in terms of the effect of the nailed footer? See that
1) the footer on the site is inside a block with id = layout, which does not have a percentage height. According to the theory, he, parents and the content block. Content-left are required to deliver a height of 100%. There are problems with the latter - it is not suitable for this. Consequently, one layer is missing or the footer is at the wrong level. Besides,
2) the height of the footer variable (depends on the number of elements in the list and on the font size, it can be seen not from HTML, but from CSS). AND
3) above the
#layout there is an ad unit with a fixed height of 90px;
4) there are no alignment blocks either in the footer or (generally speaking) in the
#layout block (there is, but above the
.rotated_posts block; however, it may be necessary to refer it to the footer).
Point 4 - it is necessary to draw a script.
With the third point to understand, it would seem, just by adding
#layout{margin-top:-90px;}
But let us remember that this block may not be - it is suppressed by a banner cutter, or its advertisers suddenly decide not to show it. There are a number of pages of the site where it is not. Therefore, the dependence of
margin-top on the ad unit is a bad idea. Much better - place it inside
#layout - then it will not interfere with anything.
The first point is that in order for the nailed footer to work at all, you need to place the footer block under
#layout . However, using javascript, you can implement other nailed footer schemes, but in any case you need JS or initially correct layout to do without it.
Since we can’t be stronger than the latest site maker who put the footer inside the content, we’ll postpone the idea of correctly placing the footer on our future site (which will be “cooler” Habr!), And prepare Habr with a javascript (user script) states. (Just say, it’s not the layout designer, not the switchman who’s to blame, but the site’s view, of course, determines the strategic decision of the project’s management.) So we’ll not reach the ideal, because in the first second or two during the loading process the page will be with the wrong layout. But for us the concept and the ability to beat the quality of the most popular site in the
world of IT people is important.
Therefore, in the right place of the script (early, at the end of the page load) we will write the hyphenation of the DOM blocks of the advertisement and footer to the right places. (Let's get ready for the fact that at the expense of userscripts the solution will be harder than a clean one.)
var dQ = function(q){return document.querySelector(q);}
Put the blocks in place - now it remains to assign the desired properties to the elements. The height of the footer will have to be set precisely, simply because we already know it by the time of the user script (the end of the page load). Because of the trigger point of user scripts, as mentioned above, a footer display jump on the page is inevitable. You can try to make a “good face”, but with a “bad game”? What for? The “bad game” of the site allows you to make a concept without super efforts, which will be enough to assess the quality and will not be needed if you “play the right game” on your project.
if(foot){
Here they allowed themselves to use the samopisny function
h.apnd_el , which does approximately the same as in jQuery -
$('<div class="clear"></div>').css({height: footH ||0}).appendTo($(footer))
And then - another typical feature for implementing CSS rules is
h.addRules . You can't do without it here, because you need to declare a rule with "
! Important " - just because of the peculiarities of the style priorities from user scripts.
With these pieces of code, we will be able to see a nailed footer in the userscript (after jumping it down) and fully understand how to build a page layout. Using a bouncing design every day is unpleasant, so it is recommended to make it exclusively for demonstration and testing. In the HabrAjax
user script, I installed a similar script by closing it with the “underFooter” setting (tick in the list of settings before the footer nailed to the bottom), starting with version 0.883_2012-09-12.
Does the nailed footer affect the need to update the
ZenComment styles, if they are installed?
Yes, it does. Due to the complex chain of priorities of styles in which styles inserted by user scripts have the lowest priority, we had to adjust users a little in order to
be able to work with a nailed footer. If you do not upgrade userstili (before 2.66_2012-09-12 +) - the footer will work inaccurately.
The rotated_post block (three popular posts from the past) looks more logical with the footer, so in the real script it is also transferred to the footer.
The second point (from the list of flaws in the layout) is the reasoning purely for Habr (the user script does not apply and partially repeats the previous ones).
Pages have a problem that prevents you from making a nailed footer on pure CSS - an undefined footer height, depending on the default font size in the browser. To implement a CSS footer, you need to select relative font heights, but they may not work if the user’s computer does not have the specified fonts. Therefore, the solution should include a javascript that can fit transitions (transitions) to approximate the position of the footer. Or, looking at the acceptability of the decision made on userscript on different platforms, make a calculated installation of the nailed footer - the first observations show that the solution is practical.
Conclusion: you can fully decorate the layout on Habré, but you need a coder who clearly understands the layout behavior and arranges the blocks in the correct order. (Now the footer and the top banner are “not there” and not so simply to get the nailed footer in styles.) You can do without JS, if you set the height of the footer in relative units, taking a certain amount of space for font uncertainty.
Implementation
If you enable
HabrAjax 0.883+, then we will see the work of the “nailed footer”. It adapts in height using scripts. It allows you to assess how much better the pages with the footer nailed compared to the usual ones. ZenComment
users are compatible with scripts, but for a nailed footer to work properly with them, you need to install the ZenComment version 2.66_2012-09-12 +.
Implementation Facts
Shamanism with footer, styles and scripts is shamanism (only supported by theory). Different browsers have slightly different behavior, but in some places it is unexpected. Without userscripts and block rearrangements, the results will be different. This is what experiments with implementation on userscripts gave.
1) Firefox - unexpected lack of footer jumping. It is strange that they are not - drawing occurs after placing the footer at the bottom.
2) Chrome - it surprised by “wandering scrolling” - empty spaces are added to the page with a period of once a second - something wrong is happening with the calculation of heights. It is treated by writing html, body {height: 100%} into users, but without guarantees that it will always work. It’s safer to check whether the document is over the window height, and if it does not exceed, then move the footer, otherwise nothing. With jumping - everything is in order, it is.
3) Opera - without jumps (v. 12.02) when you first load the page, but a hasty reload can show a footer jump. For the rest, it leads no less correctly than Fx.
Well, you have to specially accustom Chrome to behave correctly (by a script) and roll out the version for this purpose. Therefore, the site in userscript is a bit more complicated than that given in the article.
It must be recalled that this is not a complete implementation - does not take into account, for example, cases of window resize by the user. You can also find rare (in practice) combinations of varying heights of the footer before and after moving, where the logic will start to fail, not leading to inconvenience. The drawbacks are left deliberately, because there is a balance between the complexity of refinement and the temporary nature of the solution.
As a result, it turned out quite workable scheme of work, at least for fast desktop computers. If the incorrect behavior of the footer is detected, the “underFooter” setting should be disabled.
What pages is this useful for?
On a standard site, without userstyle, even short pages of question-answers are longer than 1500px, which is imperceptible in most cases with horizontal monitors. But even with ordinary monitors, users' personal pages are often found with a height of about 1300 pixels, where the unworn footer appears in all its glory. Not very long and a number of pages in the user settings.
If users use ZenComment, they greatly reduce the required page height, and the HabrAjax user script may not show some or all of the side blocks on the sidebar. Therefore, with scripts and styles, the effect of an unburned footer is noticeably more often observed. Therefore, it is logical that the fix for the footer appeared in HabrAjax for the first time. But the usual site has a number of pages where a nailed footer would be useful.
Will there be support?
The site’s behavior over the past year shows that developers (and therefore the manual) have begun to introduce features that previously existed only in user scripts and user styles. For example, at the beginning of the year I wrote a
review article on Habr's usability , where I collected many small wishes. After six months, I returned to it and noted with satisfaction (right in the text; you can familiarize yourself with “UPD” and dates) that a number of possibilities, described as wishes, have already been introduced into the site.
Next, look at the "arrows" instead of squares for evaluating comments. They appeared in users
almalexa ("Prettifier") about 3 years ago and were taken over into ZenComment about 2 years ago. About 2-3 months ago they appeared on the site. Begins to believe that after a while the arrows will spread to some distance, as was done in the ZenComment (one arrow to the left of the number, the second to the right) in order to miss less.
Therefore, perhaps, the “nailed footer” on Habré is not such a fantasy that could have seemed 3 years ago.
Other features in the HabrAjax script that appeared in the last 3 months (can be disabled in the settings):
*
autorost of input fields (in Opera can slow down on large texts);
* days of the week with dates other than "today" and "yesterday";
* events in the tape,
collapsing to 1 line and 2 characters ;
* the abbreviation of the words "Habr *" to "χ ·" and "χα";
*
date tips on article numbers - it is reported which month and year the article is before it is downloaded, by the number in the URL;
*
"Similar posts" are rolled up to 2 words.
Screenshot of pop-up "similar posts" (shows 12 links, not 4).