Варианты «clearfix-хака» и его замен: сводная таблица

Сразу напишу, что я использую такой вариант для clearfix:

.clearfix:after {
  content:" ";
  display:table;
  clear:both;
}

Вдогонку статье о новом значении свойства display, призванном избавить верстальщиков от нужды в clearfix-хаках — своего рода «шпаргалка», показывающая, в чем именно бывают проблемы с float-ами и какие из решений — исторических, теперешних и перспективных — какие из этих проблем решают (а какие — создают взамен:).

Первая строка таблицы — поведение обычного блока, без всяких что-то-фиксов. Хороший фикс должен исправить только то, что нам мешает, по возможности сохранив остальное поведение блока — которое нас вполне устраивает — неизменным. А именно:

• вписываться в свободное место по ширине, предоставляемое внешней структурой макета;
• полностью заполнять эту ширину независимо от количества контента внутри;
• не распирать внешнюю структуру макета, если контент внутри окажется шире (в крайнем случае пусть наружу блока «выпирает» только этот широкий контент);
• выступающие части контента (напр. абсолютно позиционированные или сдвинутые отриц. margin-ами) должны оставаться видимыми.

При этом мы хотим, чтобы:

• float-ы не «вываливались» из блока — его высота учитывала их (именно это обычно подразумевают, говоря «заклирить флоаты»:);
• но и float-ы, идущие в потоке раньше, не «вваливались» в него, влияя на поведение контента блока, включая его внутренние float-ы (об этом часто забывают, что приводит к неприятным сюрпризам);
• margin-ы блока, его дочерних элементов блока и соседей не «схлопывались» между собой (вообще-то для сплошного текста «схлопывание» скорее полезно, есть много доводов в его защиту, но будем честны перед собой: в подавляющем большинстве макетов никаких «выпадающих margin-ов» блоки не предусматривают).

И, само собой, это должно работать во всех браузерах. В следующей таблице видно, насколько каждое решение этим требованиям удовлетворяет.

Примечания к таблице:

¹По умолчанию блок может перекрываться с высокими float-ами, идущими в потоке раньше — они могут «проникать» в него, смещая его контент. Это стандартное поведение для блоков с текстом, но от блоков-контейнеров мы обычно ждем, чтобы они были полностью изолированы от любых других блоков. Без отдельного блочного контекста форматирования это проблематично.

²Из-за схлопывания нижнего margin-а блока и его дочернего элемента блока возможна ситуация, когда float целиком поместится в этом объединенном margin-е, а блочный элемент с clear формально окажется под ним. Визуально это выглядит так, будто clear не сработал. Именно поэтому для clearfix-хака рекомендовали display:table, а не display:block — через «прокладку» в виде таблицы, как элемент с новым контекстом форматирования (даже нулевого размера!), margin-ы схлопнуться не могут, и clearfix сработает всегда. Вот утрированный, но вполне реалистичный пример этого различия.

³::after с display:table не дает нижним margin-ам дочерних элементов блока «вывалиться» за его границу и «схлопнуться» с margin-ом самого блока. Но верхним margin-ам в этом способе, в отличие от предыдущего, ничего «схлопнуться» не мешает.

⁴В CSS2.x есть неочевидная и малоизвестная особенность, что overflow:hidden не обрезает вложенные элементы блока, абсолютно позиционированные относительно его предка. Так что, если сделать блок с двойной оберткой — position: relative у внешней и overflow у внутренней — обрезки выступающего контента можно частично избежать. Но лишь частично, так как непозиционированный контент (выдвинутый наружу margin-ами, трансформациями и т.д.) обрежется в любом случае. В варианте с overflow:auto выступающий контент остается доступен за прокруткой, но далеко не всегда это приемлемо по дизайну.

⁵По умолчанию для fieldset приоритетна ширина контента, а не контейнера (как и у таблицы). Потому что в браузерных стилях (у новых браузеров) ему задано min-width: min-content. Это можно переопределить (в некоторых браузерах — лишь хаками).

⁶По актуальному стандарту контент, выступающий из колончатого контейнера, обрезаться не должен (хотя в прошлых редакциях это то и дело менялось и до сих пор идет спор о трактовке). Но в некоторых браузерах (напр. на Blink) с этим есть баги. Например, элемент может начать обрезаться, если задать ему opacity, но перестать, если добавить will-change:opacity или backface-visibility: hidden (обнаружено в ходе создания примера для предыдущей статьи). Так что надо тщательно тестировать!

Также не забывайте, что значения display, меняющие внешнее поведение блока, могут приводить к добавочным сюрпризам. Например, с display:inline-block элемент переносится из блочного контекста форматирования в инлайновый, а с display:table-cell — оборачивается в анонимный блок с табличным контекстом (и начинает игнорировать свойство margin).

Взято отсюда http://css-live.ru/articles-css/clearfix-block-formatting-context-methods-cheatsheet.html