Как не показывать footer на странице css

Посмотрим на строение страниц нашего подопытного. Для этого проще всего раскрыть окно Firebug или подобное окно («Инструменты разработчика» (Ctrl-F12)) в Chrome.

Перейдём к рабочему примеру

Какие видим недостатки вёрстки в плане реализации эффекта прибитого футера? Видим, что
1) футер на сайте находится внутри блока с который не имеет процентной высоты. По теории, ему, родителям и блоку содержания .content-left требуется поставить высоту 100%. С последним возникают проблемы — он для такого не приспособлен. Следовательно, не хватает одного прослоечного блока или футер находится не на том уровне. Кроме того,
2) высота футера переменная (зависит от числа элементов в списке и от размера шрифта, это видно не из HTML, а из CSS). И
3) над #layout имеется рекламный блок фиксированной высоты 90px;
4) выравнивающих блоков нет ни в футере, ни (вообще говоря) в блоке #layout (есть, но над блоком .rotated_posts; впрочем, возможно, его надо отнести к футеру).

Пункт 4 — придётся прорисовывать скриптом.
C третьим пунктом разобраться, казалось бы, просто, добавив Но вспомним, что этого блока может не быть — он подавляется баннерорезкой, или рекламщики его вдруг решат не показывать. Есть ряд страниц сайта, где его нет. Поэтому зависимость margin-top от рекламного блока — плохая идея. Гораздо лучше — разместить его внутри #layout — тогда он ничем не будет мешать.

Первый пункт — чтобы прибитый футер вообще заработал, надо блок футера поместить под #layout. Впрочем, с помощью javascript можно реализовать и другие схемы прибитого футера, но в любом случае нужен JS или изначально правильная вёрстка, чтобы обойтись без него.

Поскольку мы не можем быть сильнее самого последнего верстальщика сайта, «влепившего» футер внутрь содержания, отложим идею правильного размещения футера на свой будущий сайт (который, стало быть, будет «круче» Хабра!), а Хабр препарируем джаваскриптом (юзерскриптом) до правильного состояния. (Сразу скажем, виноват не верстальщик, не стрелочник, а вид сайта, конечно, определяет стратегическое решение руководства проекта.) Так мы не достигнем идеала, потому что в первую секунду-две в процессе загрузки страница будет с неправильной вёрсткой. Но для нас важен концепт и возможность превзойти по качеству самый популярный сайт мира айтишников.

Поэтому в нужном месте скрипта (пораньше, в конце загрузки страницы) напишем переносы DOM-блоков рекламы и футера на нужные места. (Приготовимся к тому, что за счёт юзерскриптов решение будет сложнее чистого.)

Расставили блоки по местам — теперь осталось приписать элементам нужные свойства. Высоту футера придётся задавать точно, просто потому что мы её уже знаем к моменту действия юзерскрипта (конец загрузки страницы). Из-за точки срабатывания юзерскрипта, как уже говорилось выше, прыжок отображения футера на странице неизбежен. Можно пытаться делать «хорошее лицо», но при «плохой игре»? Зачем? «Плохая игра» сайта позволяет сделать без сверхусилий концепт, которого будет достаточно для оценки качества и не понадобится при «правильной игре» на своём проекте.

Здесь позволили себе применить самописную функцию h.apnd_el, делающую примерно то же, что и в jQuery —

И далее — ещё одна типичная функция внедрения правил CSS — h.addRules. Здесь без неё не обойтись, потому что нужно объявить правило с «!important» — как раз из-за особенностей приоритетов стилей из юзерскрипта.

С этими кусочками кода мы сможем увидеть в юзерскрипте прибитый футер (после прыжка его вниз) и полностью осознать, как надо строить вёрстку страниц. Использовать прыгающий дизайн повседневно — неприятно, поэтому рекомендуется его сделать исключительно для демонстрации и тестирования. В юзерскрипте HabrAjax я установил аналогичный скрипт, закрыв его настройкой «underFooter» (установить «галочку» в списке настроек перед «прибитый к низу футер»), начиная с версии 0.883_2012-09-12.

Затрагивает ли прибитый футер необходимость обновления стилей ZenComment, если они установлены? Да, затрагивает. Из-за сложной цепочки приоритетов стилей, в которых стили, вставляемые юзерскриптом, имеют низший приоритет, пришлось немного подкорректировать юзерстили для возможности работы с прибитым футером. Если вы не обновите юзерстили (до 2.66_2012-09-12 +) — футер будет работать неточно.

Блок rotated_post (три популярных поста из прошлого) логичнее смотрится при футере, поэтому в реальном скрипте он тоже перенесён в футер.

Второй пункт (из списка недостатков вёрстки) — рассуждения чисто для Хабра (к юзерскрипту не относятся и частично повторяют прежние).

У страниц имеется проблема, мешающая сделать прибитый футер на чистом CSS — неопределённая высота футера, зависящая от размеров шрифта по умолчанию в браузере. Для реализации футера на CSS требуется подобрать относительные высоты шрифтов, но и они могут не сработать, если на компьютере пользователя не будет предусмотренных шрифтов. Поэтому решение должно включать джаваскрипт, который может подгонять переходами (transitions) приблизительное положение футера до точного. Или, посмотрев на приемлемость сделанного решения на юзерскрипте на разных платформах, сделать вычисляемую установку прибитого футера — первые наблюдения показывают, что решение практично.

Вывод: полноценно оформить раскладку на Хабре можно, но для этого нужен верстальщик, чётко понимающий поведение раскладки, располагающий блоки в правильном порядке. (Сейчас футер и верхний баннер стоят «не там» и не так, чтобы просто стилями получить прибитый футер.) Можно обойтись без JS, если задать высоту футера в относительных единицах, взяв некоторый запас места на неопределённость шрифта.

Реализация

Если включить HabrAjax 0.883+, то увидим работу «прибитого футера». Он адаптируется по высоте с помощью скриптов. Он позволяет оценить, насколько лучше выглядят страницы с прибитым футером по сравнению с обычными. Юзерстили ZenComment совместимы со скриптами, но для правильной работы прибитого футера с ними нужно установить версию ZenComment 2.66_2012-09-12 +.

Факты о поведении реализации

Шаманство с футером, стилями и скриптами — это шаманство (лишь подкрепляемое теорией). В разных браузерах немного разное поведение, но кое-где — неожиданное. Без юзерскриптов и переставления блоков результаты будут другие. Вот что дали эксперименты с реализацией на юзерскрипте.

1) Firefox — неожиданное отсутствие прыжков футера. Странно, что их нет — отрисовка происходит после размещения футера внизу.

2) Chrome — он удивил «блуждающим скроллом» — к странице с периодом раз в секунду добавляются пустые пространства внизу — что-то неправильное происходит с расчётом высот. Лечится прописыванием html,body в юзерстили, но без гарантий, что всегда будет работать. Надёжнее — проверять, не превышает ли документ окно по высоте, и если не превышает, то двигать футер, иначе — ничего. С прыганием — всё в порядке, оно есть.

3) Опера — без прыжков (v. 12.02) при первой загрузке страницы, но поспешная перезагрузка может показать прыжок футера. В остальном ведёт не менее корректно, чем Fx.

Что же, придётся специально приучить Хром вести себя правильно (скриптом) и в таком виде выкатить версию на обозрение. Поэтому участок в юзерскрипте немного сложнее, чем приведённый в статье.

Надо напомнить, что это не полноценная реализация — не учитывает, например, случаи ресайза окна пользователем. Можно найти и редкие (на практике) сочетания изменяющихся высот футера до перемещения и после него, где логика начнёт давать сбои, не приводящие к неудобствам. Недостатки оставлены сознательно, потому что соблюдается баланс сложности доработки и временности решения.

В итоге, получилась вполне работоспособная схема работы, по крайней мере, для быстрых стационарных компьютеров. Если обнаружится неправильное поведение футера, настройку «underFooter» нужно отключить.

Для каких страниц это полезно?

На стандартном сайте, без юзерстилей даже короткие страницы вопросов-ответов оказываются длиннее 1500px, что в большинстве случаев незаметно при горизонтально расположенных мониторах. Но даже при обычных мониторах часто попадаются персональные страницы пользователей высотой порядка 1300 пикселей, где неприбитый футер предстаёт во всей красе. Не очень длинен и ряд страниц в настройках пользователя.

Если применять юзерстили ZenComment, они сильно сокращают необходимую высоту страницы, а юзерскрипт HabrAjax может не показывать некоторые или все боковые блоки в сайдбаре. Поэтому со скриптами и стилями заметно чаще наблюдается эффект неприбитого футера. Поэтому логично, что в HabrAjax исправление футера появилось впервые. Но и обычный сайт имеет ряд страниц, где прибитый футер был бы полезен.

Будет ли поддержка?

Поведение сайта за последний год показывает, что разработчики (а значит, руководство) начали внедрять возможности, ранее существовавшие только в юзерскриптах и юзерстилях. Например, в начале года я написал статью-обзор по юзабилити Хабра, где собрал множество небольших пожеланий. Через полгода я вернулся к ней и с удовлетворением пометил (прямо в тексте; можно ознакомиться с «UPD» и датами), что целый ряд возможностей, описанных как пожелания, уже были внедрены в сайт.

Далее, посмотрим на «стрелочки» вместо квадратиков для оценивания комментариев. Они появились в юзерсилях almalexa («Prettifier») года 3 назад и переняты в ZenComment года 2 назад. Месяца 2-3 назад они появились на сайте. Начинает вериться в то, что через некоторое время стрелки разнесут на некоторое расстояние, как это сделано в ZenComment (одна стрелка слева от числа, вторая справа), чтобы меньше промахиваться.

Поэтому, возможно, и «прибитый футер» на Хабре — это не такая фантастика, какой могла показаться года 3 назад.

Другие возможности в скрипте HabrAjax, появившиеся за последние 3 месяца (отключаемы в настройках):
* авторост полей ввода (в Опере может тормозить на больших текстах);
* дни недели при датах, кроме «сегодня» и «вчера»;
* события в Ленте, сворачиваемые до 1 строки и 2 символов;
* сокращение слов «хабр*» до «χ·» и «χα»;
* подсказки дат по номерам статей — сообщается, какого месяца и года статья до её загрузки, по номеру в URL;
* свёрнуты «Похожие посты» до 2 слов. Скриншот всплывающих «похожих постов» (показывает 12 ссылок, а не 4).

Sticky Footer, Five Ways

DigitalOcean joining forces with CSS-Tricks! Special welcome offer: get $100 of free credit.

The purpose of a sticky footer is that it “sticks” to the bottom of the browser window. But not always, if there is enough content on the page to push the footer lower, it still does that. But if the content on the page is short, a sticky footer will still hang to the bottom of the browser window.

Note that “sticky” here is exactly as described above. It’s not to be confused with position: fixed; which can be used to “stick” an element in place even if the page scrolls. Or, even more confusingly, it’s not position: sticky; either, which is liked fixed positioning inside of containers sort of.

There is negative bottom margins on wrappers

There was a wrapping element that held everything except the footer. It had a negative margin equal to the height of the footer. That was the basis of this one.

This one required an extra element inside the content area (the “ .push “), to ensure that the negative margin didn’t pull the footer up and cover any content. The push was also clever because it very likely didn’t have any bottom margin of it’s own. If it did, that would have to be factored into the negative margins, and having those two numbers not in sync doesn’t look quite as nice.

There is negative top margins on footers

This technique did not require a push element, but instead, required an extra wrapping element around the content in which to apply matching bottom padding to. Again to prevent negative margin from lifting the footer above any content.

Kind of a wash between this technique and the previous one, as they both require extra otherwise unnecessary HTML elements.

There is calc() reduced height wrappers

One way to not need any extra elements is to adjust the wrappers height with calc(). Then there is not any overlapping going on, just two elements stacked on top of each other totaling 100% height.

Notice the 70px in the calc() vs. the 50px fixed height of the footer. That’s making an assumption. An assumption that the last item in the content has a bottom margin of 20px. It’s that bottom margin plus the height of the footer that need to be added together to subtract from the viewport height. And yeah, we’re using viewport units here as another little trick to avoid having to set 100% body height before you can set 100% wrapper height.

There is flexbox

The big problem with the above three techniques is that they require fixed height footers. Fixed heights are generally a bummer in web design. Content can change. Things are flexible. Fixed heights are usually red flag territory. Using flexbox for a sticky footer not only doesn’t require any extra elements, but allows for a variable height footer.

You could even add a header above that or more stuff below. The trick with flexbox is either:

• flex: 1 on the child you want to grow to fill the space (the content, in our case).
• or, margin-top: auto to push the child away as far as it will go from the neighbor (or whichever direction margin is needed).

Remember we have a complete guide for all this flexbox stuff.

Grid layout is even newer (and less widely supported) than flexbox. We have a complete guide for it too. You can also fairly easily use it for a sticky footer.

This demo should work in Chrome Canary or Firefox Developer Edition, and can probably be backported to the older version of grid layout for Edge:

Похожие публикации:

1. Для чего node js
2. За что на веб странице отвечает css
3. Как сделать расстояние между картинками css
4. Как сделать скролл внутри блока css

Как не показывать footer на странице css

HTML-элемент представляет собой нижний колонтитул (футер, подвал) для своего ближайшего секционного контента или секционного корня. Футер обычно содержит информацию об авторе раздела, информацию об авторском праве или ссылки на связанные документы.

footer> Какая-то информация об авторском праве или может информация об авторе статьи? footer>