Расставляем точки над прижатым футером: возвращаясь к истокам

Веб разработка - CSS

Задача:

История вопроса: всё началось с этого коммента к этому топику, за ним последовало познавательное обсуждение, продолжившееся в личной переписке.

Начнем с примера №1 (смотреть в браузерах, понимающих CSS2.1 — IE8, Опере 7.5+, FF1+, любом Webkit-based и т.п.).


Классическая структура с тремя блоками. Всё валидно. Основной контент идет раньше других блоков в коде — частое требование к современной верстке ради доступности (скринридеры и т.п.), SEO и кучи других резонов. Ни грамма JS. Никаких отрицательных отступов и фиксированной высоты — высота «шапки» и «подвала» определяется их содержимым, а основной контент занимает все оставшееся место (если хватает).

Семантично? На мой взгляд, вполне. А визуально — да, это самая что ни на есть CSS-таблица, специально предназначенная (опять же, на мой взгляд) для случаев, когда положения блоков зависят друг от друга и от контейнера. За «магическую телепортацию» блоков к краям окна отвечают два значения свойства display — table-header-group и table-footer-group. Я тоже практически не слыхал о них, пока коллега Fragster не показал мне чудесный пример… из которого со временем и вырос этот топик :)

Как видим, это поддерживается давно и прочно. Вот если б не IE7 и ниже, не понимающие «экзотических» значений display… Оказывается, поведение, задаваемое этими свойствами, доступно и этим «динозаврам»! Это демонстрирует пример №2.

Для «правильных» браузеров в нем ничего не изменилось по сравнению с предыдущим. Лишь комментарии (в head и между блоками), не влияющие на семантику кода (поисковики, скринридеры и т.д. их проигнорируют). А вот в старых IE произошла «изящная деградация» к… старой доброй табличной разметке! И при этом порядок блоков в коде остался тем же, семантичным.  упс… я этого не говорил :)

Надо признаться, код, который в предыдущем примере получает IE7-, невалиден: по стандарту thead и tfoot (чье поведение имитируют table-header-group и table-footer-group) должны идти перед элементом tbody, а не после. К счастью, для «всеядного» IEшного парсера это неважно. Но иногда порядок табличных (с точки зрения визуальному отображения) элементов бывает существенным для браузерного рендерера. Так, если в примере №1 поменять местами .header и .footer, ломается отображение в Опере 9.2x и ниже: .footer выводится непосредственно под .header-ом. В современных версиях Оперы (9.5 и выше) отображение уже не зависит от порядка блоков (как и в других браузерах), но, поскольку Опера 9.2х кое-где еще занимает существенный процент, приходится учитывать эту ее особенность.

Внимательные читатели могли заметить, что в примере №2 используется expression. Единственная его роль — растянуть среднюю строку на всю свободную высоту таблицы (обход известного глюка IE7 - в стандартном режиме, игнорирующего заданную высоту строк «резиновой» таблицы и всегда растягивающего их пропорционально). Поэтому даже при отключенном JS .footer останется прижатым — лишь основной контент немного «уползет» вниз от .header-а.

Принципиально обойтись без expression возможно. Например, так, как в примере №3 (там изменен порядок блоков, что вызовет упомянутую проблему в старых Операх, но для некоторых аудиторий — напр., американской — это не критично). «Экстремалы» прогресса могут вообще перевести старые IE в Quirks mode (который там умеет нормально распределять высоту в резиновых таблицах — парадокс!), а различия в боксовой модели нивелировать CSS3-свойством box-sizing:border-box, поддерживаемым всеми современными браузерами (к тому же эта боксовая модель для многих удобнее). Лично я считаю один некритичный expression «допустимым злом». Зато в этом способе  возникает меньше других проблем, всплывших по ходу обсуждения исходного топика — конфликтов z-index-ов,  и т.п. Ну а чем в итоге пользоваться — решать, конечно же, вам!