Обновить

Комментарии 33

А чем display:flex не угодил?

Судя по этой таблице flex криво поддерживает ie11.
На практике, единственная существенная проблема с min-height. Она отлично решается кормлением IE height вместо min-height CSS-хаком: в IE11 для флексбоксов height ведет себя как min-height. Прямо как в старые добрые времена с IE6, да-да.
НЛО прилетело и опубликовало эту надпись здесь
У меня вообще есть подозрение, что в IE7 min-height починили хаком, а когда добавляли флексбоксы, забыли добавить еще одно условие в хак :)
НЛО прилетело и опубликовало эту надпись здесь
А, такое было, я толком и не понял, в чем дело, просто обошел, переверстав чуть иначе.
Спасибо, после вашего комментария стало понятно.
Не так уж и плохо, у ie10-11 есть некоторые «кривости» при поддержке flexbox, но они известны и собраны в одном месте рядом с простыми решениями

Список проблем с ie10-11 (и других браузеров) и их решения:
https://github.com/philipwalton/flexbugs#flexbugs

Плагин для postcss который сам исправит известные проблемы:
https://github.com/luisrudge/postcss-flexbugs-fixes
https://github.com/archana-s/postcss-flexbox
Согласен display:flex подходит, но по сравнению с inline-blockflex относительно новый элемент. По старой школе inline-block — привычнее, он работал еще в IE 5.5 и с тех пор его поведение не менялось, кросс-браузерность гарантирована… А по flex не все так однозначно, тут описания по поддержке, хоть спустя 5 лет после выхода гибрида можно уже и забыть о том, что кто-то там может не поддерживать — но тут чисто старая школа. :)

inline-block все таки меняет верстру, для этого попробуйте закрасить ul желтым цветом. Также иногда полезно вставлять в нужное место пустой div с классом clearfix. Пример здесь https://jsfiddle.net/qzqfadnb/6/.

display: inline-block не всегда хорош для решения этой задачи
https://jsfiddle.net/cs57yh3z/ по ссылке в примере у первого списка установлен display:inline-block, да его высота становится равна содержимому, но и ширина стала не 100%, так же если блоку установлен display: inline-block, то у этого блока появляется небольшой отступ в низу, который может подпортить верстку.

clearfix же решает эту задачу отлично.
Читайте внимательнее в статье и написано что .clearfix решает эту задачу и при этом оставляет свойство display без изменений а inline-block, меняет его.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Он добавляет после выбранного элемента псевдоэлемент, который огибает все float элементы, расположенные ниже.

Небольшая поправочка, если позволите — добавляет не после, а внутри элемента с присвоенным классом.
НЛО прилетело и опубликовало эту надпись здесь
Фактически все решения проблемы «containing floats» делятся на 2 класса — собственно clearfix-ы (добавление (псевдо)блока с clear:both в конец родителя) и разные способы создания блочного контекста форматирования. Есть старенькая, но, видимо, местами еще актуальная статья с подробным разбором плюсов, минусов и ограничений каждого варианта (и попыткой найти новый вариант с минимумом ограничений:).

В теории, стандартным решением второго класса без побочных эффектов должно стать display: block flow-root; из CSS Display 3. На практике, боюсь, это пока нигде не работает:(. Но и сама необходимость всё реже благодаря тем же флексбоксам.
Вся суть сводится к тому, что необходимо создать новый поток элементов (контекст форматирования), в котором будут находится плавающие блоки.
Достичь этого можно разными способами. В частности — изменением свойства display на inline-block, table, inline-table, table-cell, table-caption, flex, inline-flex (гриды, вероятно, тоже будут создавать новые контексты, сам не пробовал); изменением overflow на auto, scroll, hidden; изменением float на left или right; изменением position на absolute или fixed.
С display: *-flex и display: *-grid есть нюанс, что они создают не блочный контекст форматирования, а свой собственный, с другими правилами размещения блоков (в частности, переопределяют поведение самих плавающих блоков). Решается дополнительной оберткой, но это уже далеко не так изящно… Строго говоря, display: *-table тоже создает свой особый контекст (табличный), но в этом табличном контексте внутри *-table автоматически достраиваются анонимные «обертки» с table-row/table-cell, и явная обертка не нужна.
Всё верно. Собственно, каждый из этих способов (включая клирфикс) имеет свои нюансы, как положительные, так и отрицательные для решения конкретной задачи, о которых следует знать и применять по обстоятельствам. Одного солюшена для всех ситуаций, увы, пока нет. Хотя где-то в будущем уже маячат гриды, которые могут стать таким универсальным средством.
Именно, я просто хотел уточнить, что не во всех контекстах форматирования плавающие блоки останутся плавающими:). А насчет плюсов и минусов — в статье, на которую я сослался чуть выше (одновременно с вашим комментом), есть неплохой наглядный пример разницы в действии:)
Когда уже даже намек на клирфикс пропадет (
Давайте еще рассмотрим вот такой вариант.
https://jsfiddle.net/wanick/taojv46v/5/

специально добавил цвета чтобы видеть как clearfix и inline-block решают эту задачу,
У clearfix — родителя div.box не вошел внешний отступ(margin) который прописан для UL а inline-block все воспринял как нужно все отступы на месте.

Также добавил пример как для inline-block сделать width: calc(100% — 80px) — не забываем что отступы внешние и внутренние нужно исключить из ширины.
вроде как calc() плохо поддерживается во многих браузерах, в частности на телефонах. (Opera mini и UC Browser)
Соглашусь с вами, calc — не самый удачный пример, но это лишь демонстрационный пример, который показывает что ширину выставлять нужно «не забывая» про отступы.
В данном случае в втором примере (с .clearfix) поведение вполне корректное.
Не найдя внутри контейнера box каких-либо элементов, границ или padding'ов сверху и снизу, браузер рассчитал margin относительно ближайших элементов с границей: заголовка и строки «Какой-то текст» внизу. Таким образом отступы внутри box и не должны были появиться.
Если добавить, например, свойство border: 1px solid transparent для div.box, то отступы также будут видны, как и в последнем случае.

В случае же inline-block отступы всегда рассчитываются относительно родительского элемента, поэтому внутрь родителя и вошли внешние отступы ul.
Есть третий способ. Родительскому элементу прописать:
. clearfix { overflow: hidden; }

Я ненавижу inline-block за его нетерпимость к пробелам между тегами. 1 пробел — и вся верстка летит к чертям. и приходится писать из-за этого отвратительный html типа


<ul>
  <li>asdasd</li><li>
       asdasd</li>
</ul><ul>
</ul>
Достаточно просто указать для обертки font-size:0 и лишние пробелы уйдут.
А для дочерних элементов проставить размер шрифта заново.

насколько я помню, с этим тоже были какие-то проблемы, сейчас уже не вспомню...

В андроид-браузерах, как минимум.
НЛО прилетело и опубликовало эту надпись здесь

вариантов масса, но, как видите, ни один не подходит на 100% поэтому и ненависть =)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации