Проблемы CSS. Часть 1

[@vdv73rus]

Придёт flexbox, clearing с inline-block элементами умрут сами по себе.
А реализация варианта с комментариями пробелов на к.-н. шаблонизаторе та ещё задача, это в голом html всё красиво

[@d4rkr00t]

Так в шаблонизаторе можно и просто в строку вывести, как первый предложенный вариант, и тогда не будет такой проблемы. Flexbox ждем, пока ie8 и ie9 поддерживаем не получится.

[@Mithgol]

Придёт flexbox, clearing с inline-block элементами умрут сами по себе.

Не вижу связи.

Flexbox не позволяет решить задачу «поместить по горизонтали столько элементов, сколько влезет», а именно для этого чаще всего употребляется inline-block (приведённый в статье пример «контейнер размером 600px с тремя элементами внутри, размер каждого из которых 200px и задано свойство display: inline-block» — редчайший частный случай; чаще же всего ширина такого контейнера произвольно меняется по мере изменения размера окна).

[@d4rkr00t]

Хм, вроде бы позволяет: codepen.io/d4rkr00t/pen/Cqzvo

[@d4rkr00t]

пока видимо только webkit браузеры так могут

[@vdv73rus]

И FF, и ещё кое-кто. Вот хорошая презентация от pepelsbey на эту темку http://pepelsbey.net/2013/05/flexbox-gotcha/

[@d4rkr00t]

Я про flex-wrap и flex-flow

[@Mithgol]

Да; согласно сведениям на сайте «Mozilla Developer Network», Firefox не поддерживает flex-wrap.

[@torbasow]

И тут.

[@d4rkr00t]

да, да понял, не только webkit

[@1andy]

flex-wrap: wrap позволяет

[@hermit931]

Ну незнаю, с дополнительными комментариями это проще. Главное чтобы кодер не посчитал их лишними

<div class="parent"><!-- 600px
      --><div class="child">I'm a child!</div><!-- 
--><div class="child">I'm a child!</div><!--
--><div class="child">I'm a child!</div><!--
 --></div>

[@VolCh]

В идеале в html не должно быть ничего, относящегося к отображению. Хотя вопрос конкретно пробелов между тегами достаточно спорный, так как сложно различить ситуации где пробел является частью данных, которые нужно отобразить, а где используется лишь для форматирования кода. По идее это должен быть атрибут родительского тега. Либо свойство CSS по произвольному селектору, позволяющее включать и отключать игнорирование пробелов или, в более общем случае, текстовые ноды внутри контейнера. В крайнем случае какая-то новая относительная единица измерения для обозначения ширины пробела в текущем шрифте. В общем имея в виду, что в SGML-based (по крайней мере популярнех HTML и XML) языках к пробельным символам особое отношение, нужно и в css ввести особое к ним отношение.

[@Smartfon]

Обычно проблему с float'ами решаю применяя overflow: hidden для родительского элемента: jsfiddle.net/6PDmf/

[@vdv73rus]

Да, известный способ.
Но как только внутри появляется абсолютно-позиционируемый элемент, вылезающий за границы родителя, приходится отказываться.

[@Smartfon]

А в чем проблема? jsfiddle.net/alright/dPjND/1/

[@d4rkr00t]

вот в чем jsfiddle.net/2T7AY/

[@mdss]

на этот случай есть более изящное решение от Ильи Стрельцына
Пример:
jsfiddle.net/mdss/64eyb/

[@d4rkr00t]

Chrome 28. Mac. Баг остался.

[@mdss]

забыл из вашего примера удалить у родителя overflow:hidden;
jsfiddle.net/mdss/64eyb/1/
теперь все нормально

[@d4rkr00t]

Да так работает, но сопосб с clearfix мне нравится больше

[@mdss]

этот способ хорошо применять в «резиновых» макетах, где один из блоков фиксированный по ширине, а другой занимает всю оставшуюся ширину

[@KReal]

вот в чём: jsfiddle.net/dPjND/3/

[@GruZZ]

Возможно, я зря это сюда пишу, т.к. сам противник очистки потока через overflow:hidden;, но с помощью дополнительной обёртки проблема решаема: jsfiddle.net/GruZZ/bXbe5/1/

[@dshster]

«Дополнительная обёртка» первый друг верстальщика, простите.

[@torbasow]

Это на какой язык перевод?

[@d4rkr00t]

Настолько плох?

[@torbasow]

Вы бы сами хоть перечитали.

[@ilyautkin]

То есть, этого на хабре недостаточно?

[@lolmaus]

SASS плюс Compass легко решают все эти и многие другие проблемы.

Не совсем в тему пример: responsive галерея (попробуйте поиграть с шириной окна). sassbin.com/gist/5670191/

[@VolCh]

Каким образом решают?

[@lolmaus]

Понятно, что SASS для браузера не может предложить ничего, на что не способен CSS. Но существующие решения, которые на чистом CSS являются занозой в заднице, с SASS применяются легко и непринужденно.

Так, для очистки float'ов етсь целый арсенал решений. Я предпочитаю Toolkit:

#some-container
  @extend %clearfix-micro

 
Что касается проблемы пробелов между inline-block'ами, удалить пробелы можно средствами Haml (раз, два), если, конечно, вам посчастливилось использовать этот язык для разметки. Но по сути проблема пробелов существует, только покуда вы применяете inline-block'и для решения задач, для которых они изначально не предназначены. Я считаю, этот прием — из категории «голь на выдумки хитра». Для выстраивания элементов в ряд есть и другие способы, делать их обзор в этом комментарии считаю излишним.

 

Проблема понимания контекста — это вообще смешно, танцору мешают собственные шнурки. Но и тут SASS может предложить удобные инструменты.

Вот, к примеру, intrinsic ratio из того же Toolkit. Этот mixin позволяет одной строчкой (например, +intrinsic-ratio(4/3, 50%)) задать пропорции для контейнера (в данном примере 4 к 3), имеющего динамическую ширину (в данном примере 50% от ширины родителя). Содержимое контейнера при этом растягивается на весь контейнер при помощи абсолютного позиционирования.

Этот прием очень удобен для вставки изображений, видео и iframe'ов в responsive дизайн. Демонстрация: sassbin.com/gist/6172280/

[@kirugan]

Обсуждаемую проблему с inline-block можно решить иначе: у родителя ставится font-size: 0px, но у детей нужно проставить первоначальный размер шрифта родителя.

[@d4rkr00t]

в статье есть такой способ и рассказаны его минусы

[@GruZZ]

Кстати, некоторые проблемы webkit'ов можно решить с помощью нулевого svg-шрифта и подключать его как font:0/0 'null', a;.

Пример самого шрифта:
7days.ru/bitrix/templates/7dn-main/css/fonts/w-webfont.svg

@font-face {
	font-family: "null";
	font-style: normal;
	font-weight: 400;
	src: url('fonts/w-webfont.svg#null') format("svg");
}

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

[@kirugan]

Я буду читать статью до конца, прежде чем написать комментарий
Я буду читать статью до конца, прежде чем написать комментарий
Я буду читать статью до конца, прежде чем написать комментарий

[@tmnTurtle]

Не являюсь frond-end экспертом, хотя стараюсь прокачиваться в этом направлении.
Взял за привычку в кастомных стилях ставить следующий css-селектор

* {
  margin: 0;
  padding: 0;
  position: relative;
  box-sizing: border-box;
}

Волнует как раз position. Логика такая, что relative элемент без смещения находится на том же месте, что и static, но при этом допускает абсолютное позиционирование дочерних элементов, да и, если появляется такая необходимость, сам может быть смещен, что, в общем-то, очень удобно.

Внимание, вопрос: есть ли здесь какой-либо подводный камень, и надо ли мне дать по рукам за то, что так делаю?

[@Quilin]

Ну вы рано или поздно просто огребете, что ваш абсолютно спозиционированный элемент начнет вычислять свои координаты относительно первого же предка. Это не так чтобы проблема (на первый взгляд), но неочевидно.
Еще понаогребаете с z-index'ами, их у вас будет чуть ли не на каждый элемент, который следует за родительским блоком абсолютно спозиционированной ноды.
Еще селекторы * — очень медленные и ускорить их вообще нечем.
Вдобавок ко всему это совсем неочевидно. Все равно как если бы в вашем проекте все классы реализовывали бы некий интерфейс IMyInteface, в котором есть какой-то метод, вообще мало что имеющий общего с большей частью реализаций.

[@tmnTurtle]

Окей, уяснил. Спасибо.

[@truezemez]

You might get up in arms about the universal * selector. Apparently you’ve heard its slow. Firstly, it’s not. It is as fast as h1 as a selector. It can be slow when you specifically use it like .foo > *, so don’t do that. Aside from that, you are not allowed to care about the performance of * unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images.

www.paulirish.com/2012/box-sizing-border-box-ftw/

[@Quilin]

unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images.

Круто, что именно этим я и промышляю.

[@tmnTurtle]

Минуса за вопрос, куда катится этот мир?

[@tmnTurtle]

Курение, знаете ли, тоже вредно, но я не видел, чтобы в курильщиков камнями бросались.

[@zhart]

Спасибо, полезная статья.

<grammar-nazi> Правда, излишняя любовь автора к запятым немного ухудшает читаемость ;) </grammar-nazi>

С тех пор, css, прошел долгий путь.

Давайте, лучше, попробуем, что нибудь еще.

Позиционирование, начинающим, дается с большим трудом.

[@Valeratal]

про отступы у inline-блок не знал, спасибо ) (как раз недавно столкнулся)

[@leoni4]

По поводу inline-block элементов и пробела между ними.
А именно про способ: «отрицательный margin»

Еще один подход к решению задачи, очень похож на предыдущий, но с использование отрицательного отступа. Главный его недостаток он не работает в IE 6/7. Плюс нам необходимо убрать отступ с первого элемента, что бы они ровно встали внутри нашего контейнера.

.child {
    margin-left: -0.25em;
}
 
.child:first-of-type {
    margin-left: 0;
}

Нам не нужно удалять маргин, у первого элемента
И более того это работает в IE 6/7/8 если указывать <!DOCTYPE >
Нужно просто использовать селектор +

.child + .child {
    margin-left: -0.25em;
}

Сам я такой метод никогда не использую
Но раз уж автор разбирает проблемы CSS странно, что он указал способ с очищением для :first-of-type