Эта книга, написанная создателями css-live.ru (Максимом Усачёвым aka psywalker и Ильёй Стрельцыным aka SelenIT), посвящена одной из самых важных и вместе с тем самой загадочной, неизученной, неоднозначной и полной неочевидных сюрпризов стороне действующей спецификации CSS — визуальному форматированию текста.
В блочном контексте форматирования поля (margin), отступы (padding) и границы (border) могут оказывать влияние на любые координаты и расположение элемента, и так же могут влиять на окружающий контекст. Но что происходит в этом плане в инлайновом контексте? Давайте разберёмся.
Спецификация сообщает нам, что в инлайн-форматировании горизонтальные margin, border и padding между инлайн-боксами учитываются, а вот вертикальные не дают никакого эффекта и не могут влиять на окружающий контекст. Да, сразу стоит уточнить, что речь идет о инлайн-боксах, создаваемых обычными элементами с display:inline (читайте первую часть цикла), а не об инлайн-блоках или замещаемых элементах вроде картинок.
Некоторым может показаться, что здесь всё прозрачно, но на самом деле это не так. Поэтому я решил, что нам следует подробнее разобрать эти моменты, и начнём мы, пожалуй, с margin.
В основе этой статьи лежит перепевка спецификации CSS 2.1 по телефону Рабиновичем SelenIT-ом. Если что-то вышло криво — я не виноват, это всё он. Конструктивная критика и предложения по улучшению материала приветствуются!
Перед тем как погрузиться в мир инлайнового контекста, мне казалось, что это не очень сложная тема, и что понять её будет не трудно. Но, чем больше я углублялся в процесс изучения, тем больше понимал, что это далеко не простая и даже очень обширная и сложная тема для понимания.
Ещё больше я боялся за то, что не смогу передать на бумаге все тонкости и особенности построения этого механизма нашим читателям. Поэтому каждую статью цикла я буду стараться писать так, чтобы каждая её деталь была написана на доступном и понятном языке.
Ну, как говорится — с Богом!
Я давно собирался написать эту статью, но на прошлой неделе W3C дал замечательный повод… впрочем, обо всём по порядку. Кстати, спецификации W3C зря считают скучными: порой они могут дать фору любому детективу. В хорошем детективе всё выясняется лишь на последней странице. Но бывало ли, чтобы ключевая деталь детектива ― например, что злодеев было не двое, а трое ― раскрывалась вообще не в тексте, а… в списке найденных опечаток, на отдельном листке, вклеенном в книгу?
Так вот, в спецификациях W3C бывает еще и не такое. Например, всем нам знакомая спецификация CSS2.1: уже три года как она в статусе рекомендации, по идее, никаких изменений в ней быть не должно. Как вы думаете, сколько в этой спецификации описано наших любимых контекстов форматирования: два ― инлайновый и блочный? А вот и нет: три! Через год после «совсем-совсем-окончательного» утверждения спецификации ее авторы внезапно поняли, что на самом деле в ней описан еще один, ни на что не похожий, контекст форматирования ― табличный. Но поскольку менять окончательно утвержденную спецификацию по правилам игры нельзя, то единственное, куда можно было внести изменение ― список замеченных ошибок (errata). Так что внимательно читайте спецификации, и не только основной текст, но и добавочные ссылки! Кстати, кто пройдет квест на внимательность в оглавлении этой самой спецификации и найдет ее «секретный уровень» с одной загадочной фразой?
Но хватит вступлений, пора переходить к нашей первой теме, и это…
Итак, какие они вообще бывают, по состоянию на середину-конец 2014 года?
Эта статья задумана как начало цикла про загадки, сюрпризы, малоизученные особенности и маленькие полезные секреты самого могущественного, пожалуй, свойства в CSS — свойства display. У нас уже были статьи про новинки этого свойства — значения contents (что это вообще, его сюрпризы, преимущества и подводные камни для доступности) и flow-root. Но и старые, давно знакомые (казалось бы) значения этого свойства таят в себе немало сюрпризов, подводных камней и удивительных открытий. Прежде всего, пожалуй, это значения с «приставкой» inline-: inline-flex, inline-grid, inline-table, и, наконец, наш старый знакомый inline-block.
С него-то мы и начнем наш экскурс в фундаментальные глубины CSS образца 2018 года, в конце которого у нас должно сложиться целостное представление обо всех существующих механизмах раскладки в браузере. Готовы к сюрпризам?
Почти пять лет назад на нашем сайте вышла статья о том, как выстроить некие однотипные блоки (товары в каталоге, фото в галерее…) по сетке, оптимально вписанной в доступное пространство. Сейчас она — одна из самых популярных на сайте, и число ее просмотров всё растет. Ведь актуальность задачи никуда не делась. Самое время вернуться к этой теме и раскрыть ее по-новому.
Будни фронтенд-разработки то и дело подбрасывают нам задачки с взаимоисключающими условиями, а ограничения HTML и CSS делают их решение и вовсе невозможным (впрочем, за радость от преодоления этой «невозможности» многие из нас и любят эту работу).
Годами для многих, казалось бы, элементарных задач приходилось выбирать решение по принципу меньшего из зол. Сейчас стало полегче благодаря флексбоксам, вот-вот станет еще легче благодаря гридам. Но все системы раскладки, даже самые передовые, упираются в фундаментальное ограничение: CSS привязывается к DOM-элементам. А значит, нельзя собрать вместе и красиво вывести в одном контейнере дочерние элементы разных DOM-предков — как бы удобно, красиво, логично и адаптивно это ни было.
Так вот: теперь можно освободить элементы из-под этого «DOMашнего ареста» и работать с элементами разных уровней вложенности как с непосредственными соседями. Правда, пока в Firefox (добавлено 25.05.2017: уже не только, в Chrome 58+ примеры тоже работают, но нужно включить флаг «Экспериментальные функции веб-платформы» в chrome://flags, добавлено 06.12.2017: а теперь еще и в Safari TP 45, добавлено 07.03.2018: и наконец в стабильном Chrome 65+ без флага!). Так что желательно открыть один из этих браузеров, чтобы увидеть примеры в действии.
До этого момента мы обсуждали значения text-align, которые, во-первых, принадлежат спецификации CSS2.1, а во-вторых, уже давно существуют и работают во всех известных нам браузерах. Но прогресс не стоит на месте и на пороге уже стремительно вырастает CSS3, который дарит нам новые модули и значения для известных свойств. И здесь он не остался к нам равнодушен, предложив ещё несколько значениий для text-align, которые уже есть в CSS3, но содержатся в черновике.
Несмотря на то, что новые значения ещё черновики, я посчитал необходимым их обсудить, поэтому продолжим нашу беседу.
Горизонтальное выравнивание по ширине строки
Сдвиги междусимвольных или межсловных горизонтальных координат полезны в основном там, где необходимо поработать над красотой текста или отдельных символов. Но бывают задачи более глобального масштаба, когда нужно передвинуть не просто маленькую буковку, а, например, выровнять весь текст по середине строки или равномерно растянуть слова по ширине последней и т.д. Для таких задач в CSS тоже имеется конкретный арсенал, с которым нам и предстоит познакомиться в этой части рассказа.
Итак, мы наконец-то подобрались к завершающей части рассказа про строчное форматирование. Мы уже отлично понимаем, как работает вертикальное выравнивание и от чего зависит высота строки, но для полного понимания форматирования строк этого недостаточно. Ведь, если есть вертикальное выравнивание, то должно быть и горизонтальное.
В следующих статьях мы постараемся разобрать, что из себя представляют: ширина кегельных площадок, расстояния между ними, а так же разные способы и алгоритмы влияния на эти межсловные и межсимвольные пробелы.
Если вы внимательно читали предыдущие статьи, то уже наверняка поняли, как по отдельности работают vertical-align и line-height. Но как эти свойства взаимодействуют между собой? Краткий ответ – практически никак: их работа напрямую не пересекается. Задача vertical-align — сдвигать базовую линию, на сколько велено, а задача line-height (благодаря half-leading'ам) — отталкивать чужие лайн-боксы от этой базовой линии сверх метрик шрифта.
Если с вышеупомянутыми значениями было всё достаточно прозрачно, то с top и bottom не всё так просто. У этих значений есть особая черта, которой нет ни у одного другого значения vertical-align. Инлайн-боксы с vertical-align и значениями top или bottom способны отвязывать себя от базовой линии.
Но всё же, давайте по порядку.
В прошлых статьях мы узнали, что такое базовая линия и высота строки (line-height), но на этом история далеко не закончена. Помимо базовой линии есть и другие части лайн-бокса, по которым может происходить выравнивание инлайн-боксов или обычного текста, а, следовательно, от этого может меняться и сама высота строки.
В следующем цикле статей мы постараемся досконально углубиться в работу vertical-align, разобрать поведение этого свойства и способы его влияния на высоту строки.
В комментариях (1, 2) к предыдущей публикации нашего цикла внимательные читатели указали, что не все браузеры одинаково (по спецификации) определяют базовую линию для инлайн-блоков и инлайн-таблиц. Сюрприз: две наиболее заметные ошибки — в браузерах на движке webkit, которые всегда славятся хорошей поддержкой модных CSS-новинок. Вот эти ошибки:
1. Overflow инлайн-блоков не влияет на положение их базовой линии (ссылка на баг).
2. Инлайн-таблицы выравниваются не по базовой линии первой строки, а по нижней границе всей таблицы. Этот баг уже исправлен и ближайшие релизы вот-вот начнут вести себя по спецификации.
Поведение замещаемых элементов отчасти напоминает поведение инлайн-блоков по отношению к высоте строки, но в остальном они всё же отличаются. Но, давайте по порядку…
Несмотря на то, что инлайн-блоки (inline-block), так же как и инлайн-таблицы (inline-table) входят в инлайновое форматирование строк, они имеют свои особенности, которые отличаются от особенностей обычных инлайн-элементов или текста. Это довольно-таки интересно и нам следует о них поговорить.
Эти боксы — особенные: снаружи они ведут себя как неразрывные инлайн-боксы (наподобие отдельных слов текста), но внутри у них — свои собственные, обособленные блочные «миры», блочные контексты форматирования (о них мы расскажем в скором будущем). У инлайн-блока всё его содержимое представляет собой такой «блочный мир» (поэтому он и инлайн-блок), а у инлайн-таблицы отдельный блочный контекст создается каждой ячейкой. И в каждом из этих «маленьких блочных миров» могут находиться собственные лайн-боксы, а в них — инлайн-боксы, как обычно.