line-height для инлайн-элементов

Элементы с display:inline, как мы уже знаем, создают инлайновые боксы. В главном они ведут себя так же, как обычный текст, но могут иметь собственный фон, границы и т.п. Как же влияет line-height на них? Это мы прямо сейчас и выясним.

Начнём с того, что высота инлайн-бокса определяется либо действующим значением line-height, либо характеристиками шрифта (читайте про метрики и площадки шрифта в третьей части). Это касается случая, когда инлайн-бокс не пуст, т.е. содержит хотя бы один любой символ. В противном (пустом) случае высота инлайна схлопывается в ноль.

Простейший пример:

<p><span>span</span></p>

	p {
		border: 1px solid #000;
		background: #F90;
		padding-left: 20px;
		width: 80px;
	}
	span {
		font-size: 30px;
		background: #FC6;
	}

И результат:

В данной ситуации высота лайн-бокса, содержащего наш инлайн-элемент (<span>), равна высоте площадки в данном шрифте, т.е здесь повторяется та же ситуация с метриками шрифта и площадками, о которых мы говорили в предыдущей части.

line-height меньше или больше размера шрифта

Я решил объединить те два случая, когда line-height больше или меньше самого размера шрифта у инлайнов, потому что они схожи с таковыми же для простого текста, а значит, практически ничего нового мы тут для себя не откроем. Но всё же код и результаты следует увидеть.

<p class="minus"><span>span</span></p>
<p class="plus"><span>span</span></p>

	p {
		border: 1px solid #000;
		background: #F90;
		padding-left: 10px;
		width: 80px;
		margin: 40px auto;

	}
	.minus span {
		font-size: 30px;
		background: #FC6;
		line-height: 10px;
	}

	.plus span {
		font-size: 30px;
		background: #FC6;
		line-height: 100px;
	}

Оба результата сразу:

Когда line-height инлайнов больше или меньше размера шрифта (площадок, вычисленных метриками), в дело вступают уже знакомые нам "leading" и, следовательно, half-leading-и с обеих сторон. В первом случае (отрицательном) они уменьшают высоту строки из-за того, что half-leading-и у площадок становятся отрицательными, а во втором (положительном) наоборот – увеличивают строку по высоте, добавив при этом лишние "свинцовые бруски" к нашим площадкам. В общем, всё тоже самое, что и с обычным текстом.

Ну, и конечно же, в случае с маленьким line-height не следует забывать о наложении строк.

line-height + границы и отступы

В случае,  если мы захотим назначить нашим инлайнам padding, border или  margin, то последние никак не повлияют на высоту строки, так как эти свойства по вертикали не оказывают влияния на окружающий контент (об этом мы уже говорили в предыдущей статье).

В последнем коде я сделал некоторые изменения, добавив к нашим инлайн-элементам padding и border

	p {
		border: 1px solid #000;
		background: #F90;
		padding-left: 10px;
		width: 100px;
		margin: 40px auto;

	}
	.minus span {
		font-size: 30px;
		background: #FC6;
		line-height: 10px;
		padding: 100px 0;
		border: 10px solid #000;
	}

	.plus span {
		font-size: 30px;
		background: #FC6;
		line-height: 100px;
		padding: 100px 0;
		border: 10px solid #000;
	}

И вот что получилось:

Визуально может показаться, что отступы и границы расширили по высоте сами площадки, но это не так. На самом деле площадки остались той же высоты, что и были после расчёта метрик шрифта, а padding и border добавили к ним лишь визуальные фон и границы, не влияя при этом на их положение по вертикали.

Грубо говоря, мы имеем следующее: полоску с границей (border), далее идёт полоска пространства с фоном (padding), потом сама площадка, потом опять пространство с фоном (padding), ну и завершает всю эту конструкцию снова граница (border).

Вследствие чего можно сделать вывод, что "leading" и (padding или border) — это совершенно разные вещи, которые никак не пересекаются, не относятся друг к другу и выполняют в строке, каждый свои функции. Например, padding визуально добавляет к площадке место с тем же фоном, но на положение по вертикали не влияет, а вот "leading", наоборот, влияет только на положение площадок и на сдвиг их координат.

Высота строки при разных инлайн-боксах и line-height

Мы выяснили, как вычисляется высота строки, если в ней содержится всего лишь один инлайн-элемент, но какова будет она, если скажем лайн-бокс будет состоять не только из инлайн-элемента, но ещё и какого-нибудь текста или другого инлайна?

Разберём на примере:

<p> Before <span> Span Text Span</span> After </p>

p {
	border: 1px solid #000;
	background: #F90;
	padding-left: 10px;
	width: 400px;
	line-height: 50px;
	font-size: 40px;
}
	p span {
		background: #FC6;
		line-height: 150px;
		font-size: 12px;
	}

Посмотрим результат:

Ситуация следующая. Есть строка, в которой содержатся два анонимных инлайн-бокса (текста) и "натуральный" инлайн-бокс (инлайн-элемент <span>). Последний, надо заметить, находится ровно по середине. Примерные площадки у текста и инлайн-элемента я выделил специальными цветами для того, чтобы вы могли лучше представить происходящее. Не смотря на то, что сам текст и его площадки явно превышают по высоте площадку инлайн-элемента, они вынуждены подстраиваться именно под него, а не наоборот. Почему так происходит? Давайте разберёмся…

Дело в том, что дефолтное поведение лайн-боксов в блоке определяется размером шрифта (font-size) и высотой строки (line-height), указанным для самого блока (или теми значениями font-size и line-height, которые выходят для блока по итогу всех каскадов и наследований), а всё, что внутри — переопределяется. Исключения вынуждены приспосабливаться под общие правила. В нашем случае исключением является инлайн-элемент, потому что его размеры шрифта и высота переопределены и явно отличаются от шрифта и высоты строки самого блока. Несмотря на свои малые размеры, он выстроился по базовой линии, которая берётся по основному тексту. Именно такое поведение "исключений" и является подстраиванием под общие правила.

font-size нашего блока равен 40px, line-height 50px, а это означает, что высота текста в блоке будет 50px, включая площадки и "leading". Но почему же тогда общая высота строки у нас получилась 150px? А всё дело в том, что в таком поведении лайн-бокса виновато именно наше "исключение" (инлайн-элемент). У последнего выставлен line-height в значении 150px, что заставляет его "leading" распирать строку. Следовательно, высота инлайн-элемента теперь становится больше родительского лайн-бокса, и он в итоге и определяет фактическую высоту общей строки, центрируется в ней и подтягивает за собой базовую линию всей строки.

Базовая линия — это своего рода проволока, на которой сидят все «буквы-птицы», независимо от их размера. И только в самом высоком инлайн-боксе буквы не могут двигаться, т.к. жёстко зафиксированы half-leading-ами  (чтобы обеспечить требуемый line-height) и поэтому двигаться приходится всем остальным буквам. За счёт чего и происходит "подтягивание" общей базовой линии.

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

Другие публикации цикла

1. Введение в инлайновый контекст форматирования (ИКФ): основные понятия (1-я публикация цикла “Тайны CSS2.1″).

2. Введение в инлайновый контекст форматирования (ИКФ): основные понятия (2-я публикация цикла “Тайны CSS2.1″).

3. ИКФ: высота строки, часть 1 (3-я публикация цикла “Тайны CSS2.1″).

4. ИКФ: высота строки, часть 2 (4-я публикация цикла “Тайны CSS2.1″).

6. ИКФ: высота строки, часть 4 (6-я публикация цикла “Тайны CSS2.1″).

7. ИКФ: высота строки, часть 5 (7-я публикация цикла “Тайны CSS2.1″).

8. ИКФ: Вертикальное выравнивание в строке, часть 1 (8-я публикация цикла “Тайны CSS2.1″).

9. ИКФ: Вертикальное выравнивание в строке, часть 2 (9-я публикация цикла “Тайны CSS2.1″).

10. ИКФ: Вертикальное выравнивание в строке, часть 3 (10-я публикация цикла “Тайны CSS2.1″).

11. ИКФ: Горизонтальное выравнивание, часть 1 (11-я публикация цикла “Тайны CSS2.1″).

12. ИКФ: Горизонтальное выравнивание, часть 2 (12-я публикация цикла “Тайны CSS2.1″).

Нам необходимы ваши конструктивные коментарии в наших статьях! Пожалуйста, не проходите мимо.

P.S. Это тоже может быть интересно:

• Тёмная сторона CSS: выходим за рамки и взрываем звезды с border-image и градиентами
• «Запашки» кода React-компонентов
• Как читать W3C-спецификации