Давайте предположим, что у вас есть CSS анимация для background-color, которая меняет цвет от желтого (#cc0) к голубому (#079) в бесконечном цикле. Код для этого может выглядеть примерно так:

@keyframes color {
  from { background: #cc0 }
  to { background: #079 }
}

div {
  animation: color 3s infinite;
}

Представим последовательность анимации в линейном виде (на рисунке три итерации):

Как видно, переход между конечным состоянием одной итерации цикла и начальным состоянием новой очень резкий. Можно было бы, конечно, изменить ключевые кадры, чтобы смягчить его. Но есть способ лучше. Свойство с именем animation-direction дает некоторую степень контроля над порядком проигрывания анимации, что позволяет избавиться от резких переходов. Оно также действует на временные функции (timing-function), что позволяет сделать переходы еще плавней.

В ранних вариантах спецификации были доступны только значения normal и alternate. Результат действия первого можно наблюдать на примере выше. alternate же изменяет направление проигрывания в каждой второй итерации, в результате получается следующая последовательность (обратите внимание как была инвертирована вторая итерация):

Последнее изменение, внесенное в черновик спецификации, добавляет еще два значения: reverse, которое переворачивает каждую итерацию, и alternate-reverse, которое по сути является комбинацией alternate и reverse. Вот обобщение того, как эти четыре значения влияют на анимацию:

Проблема

Я была рада увидеть, что reverse и alternate-reverse наконец-то добавлены в спецификацию, но что-то в синтаксисе не сходилось. Изначально я думала, что четыре значения по сути вляют на два переключателя:

• Проигрывать в обратном порядке все итерации? Да/нет
• Проигрывать в обратном порядке четные итерации? Да/нет

Достаточно бессмысленно запоминать четыре отдельных значения. Я выдвинула предложение о том, что вместо этого они должны быть разделены на два ключевых слова, что упростит не только запоминание, но и грамматику.

Предложение было хорошо встречено одним из соавторов спецификации по анимации (Sylvain Galineau), но возник вопрос, не будет ли сочетание normal c alternate или reverse путать еще больше, вместо того, чтобы упростить понимание. И это вопрос, в котором ваше мнение было бы очень полезно. Как вы думаете, нижеприведенные примеры выглядят работоспособными и логичными, или же вызывают лишние вопросы?

• animation-direction: normal alternate; /*эквивалент animation-direction: alternate; */
• animation-direction: alternate normal; /*эквивалент animation-direction: alternate; */
• animation-direction: normal reverse; /*эквивалент animation-direction: reverse; */
• animation-direction: reverse normal; /*эквивалент animation-direction: reverse; */

Идея получше(?)

Пока я писала этот пост и рассматривал примеры выше, меня осенило. Эти значения – не комбинация двух состояний! Все четыре значения влияют на то, какие итерации проигрываются в обратном порядке:

• normal – не реверсирует ни одной итерации
• reverse – реверсирует все итерации
• alternate – реверсирует четные итерации
• alternate-reverse – реверсирует нечетные итерации

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

Я подумала, что проще было бы сделать свойство animation-reverse (или animation-iteration-reverse), которое бы принимало одно из следующих значений:

• none (эквивалент animation-direction: normal)
• all (эквивалент animation-direction: reverse)
• even (эквивалент animation-direction: alternate)
• odd (эквивалент animation-direction: alternate-reverse)

Этот вариант не только лучше описывает конечный результат, но и более гибкий. Например, если в будущем окажется, что проигрывание в обратном направлении каждой третьей итерации распростанено, то можно было бы легко добавить выражения для этого, аналогичные тем, которые принимает селектор :nth-child().

Еще до того, как предлагать это, я знала, что уже слишком поздно для таких радикальных изменений в модуле анимации, но идея кажется настолько хорошей, что за нее стоит побороться. К тому же, animation-direction еще не нашло широкого применения.

К сожалению, похоже, только я и Сильван думаем, что это лучше того, что есть, но даже он неохотно поддерживает мой вариант, в основном из-за проблем с обратной совместимостью. Так что я начала сомневаться, такая ли это хорошая идея, как мне представляется. Что вы думаете? Сделает ли внесение этого изменения проще процесс обучения и использования? Отзывы чрезвычайно полезны для стандартизации, так что, пожалуйста, высказывайте свое мнение в комментариях, даже без обоснования, если у вас на него нет времени и желания. Сбор мнений крайне важен.

Для тех, кто не читал

1. Удобнее ли использование alternate reverse и reverse alternate (в обоих вариантах), чем alternate-reverse в качестве значений для animation-direction?
2. Если да, должны ли быть доступны избыточные сочетания normal c alternate и reverse, например normal alternate?
3. Или, может, отказаться от всего этого разом и ввести свойство animation-reverse, принимающее значения none, all, even, odd?

Перевод статьи Is animation-direction a good idea? автор Lea Verou

После Великого Апрельского Браузерно-Префиксного Тарарама пришла Великая Майская Адаптивно-Картиночная Шумиха 2012-го.

Адаптивные изображения — очередная неразгаданная загадка «отзывчивого» веб-дизайна. Вы отдаете большие картинки высокого разрешения, подходящие для экранов типа «ретины», которые устройства с меньшим разрешением показывают уменьшенными, зря расходуя трафик? Или вы отдаете картинки низкого разрешения, которые мерзко выглядят, будучи растянутыми на большом экране? Вебмастерам приходится рассчитывать на искусные хаки, чтобы отдавать различные контентные картинки (т.е. <img> в HTML, а не CSS-фоны) для разных типов устройств.

В ноябре 2011-го я был настолько разочарован тем, что никто из авторов спецификации даже не рассматривает проблему, что я предложил «для затравки» элемент <picture>, использовавший тот же механизм переключения исходных файлов, что <video> в HTML5:

<picture alt="злой пират">
   <source src=hires.png media="min-width:800px">
   <source src=midres.png media="min-width:480px">
   <source src=lores.png>
      <!-- запасной вариант для неподдерживающих браузеров -->
      <img src=midres.png alt="злой пират">
</picture>

Примерно в то же время другие независимо пришли к той же мысли, и им было предложено создать общественную группу W3C для обсуждения этого, что они и сделали. Однако, в январе редактор HTML5 Айэн Хиксон сказал:

В каких случаях это может быть нужно для картинок в <img>? Как правило, элемент <img> служит для картинок в контенте, где обычно не нужно ничего адаптировать.

Энтузиазм тех веб-разработчиков из Общественной группы адаптивных изображений W3C порядком сник оттого, что их игнорируют, поскольку самой проблемы никто в упор не видит. Но на этой неделе Эдвард О’Коннор из Эпла предложил другой метод, использующий новый атрибут srcset элемента <img>. Это дополнило его же февральское аналогичное предложение по поводу img-set в CSS, которое уже вошло в WebKit:

<img src="foo-lores.jpg"
     srcset="foo-hires.jpg 2x, foo-superpuperhires.jpg 6.5x"
     alt="годный Alt-текст для foo.">

Числа «2» и «6.5x» говорят браузеру об относительных разрешениях: у foo-hires.jpg разрешение в 2 раза больше, чем у foo-lores.jpg.

Спустя всего несколько дней вариант эпловского предложения был добавлен в спецификацию.

Между <picture> и srcset — два важных различия. Самое очевидное — то, что srcset использует элемент <img>, что замечательно, поскольку это самое логичное место для картинок, адаптивных и нет (с <img> не пройдет тот же фокус, что с <video> + <source>, потому что это — пустой элемент, у которого не может быть потомков; решение О’Коннора использует атрибуты, что хорошо).

Второе важное отличие в том, что оно не использует медиавыражений. С медиавыражениями вебмастеру приходится думать о любых изменениях размера области просмотра, ориентации, плотности пикселей, глубины цвета, соотношения сторон и т.п., решать, как угодить им (если придется), определять границы перехода и выражать всё это в коде. Это порядком напрягает мозги разработчика и выливается в «много букв» кода: страничка с 20 картинками, каждая с 5 медиавыражениями для 5 элементов <source>, быстро разрастается в объеме кода.

О’Коннор написал:

Почему указывать масштаб, а не медиавыражение? Ну, медиавыражения — это требования к состоянию браузера, тогда как мы утверждаем что-то об отношениях между ресурсами картинок. Кроме того, браузеры должны быть свободны в использовании того ресурса, который, на их взгляд, лучше всего подходит к текущей ситуации, учитывая не только «медиавыражаемые» вещи типа разрешения устройства, но и масштаб, заданный для <img> через CSS, его атрибуты width=”" и height=”", и даже вещи вроде текущего масштаба всей страницы.

Я хорошо понимаю идею позволить браузеру самому, исходя из того, что он «знает» о своем окружении (скорость соединения, задержка сигнала, плотность пикселей, ориентация), выбирать наилучшую картинку для текущей задачи. Суть в том, что вебмастерам не нужно задумываться о каждой из этих переменных и угождать каждому варианту. Они могут лишь описать заведомо известные им вещи — картинки, их размер и плотность пикселей — а браузер уже сам сделает нужный выбор.

Таким образом, когда мы все будем жить в космосе и смотреть 3D-голограммы, устройство на iDroid3000 сможет само определить близость черной дыры (черные дыры, как известно каждому школьнику, вызывают «тормоза» голограмм) и выбрать правильную картинку; нам не придется изобретать медиавыражений для близости черных дыр и задним числом дописывать их на сайты.

У решения с srcset есть две проблемы. Первая очень субъективна, но многие чувствуют то же самое: в том виде, как оно есть в текущем, первом черновике спецификации, синтаксис просто отвратителен!

<img src="face-600-200-at-1.jpeg" alt=""
	srcset="face-600-200-at-1.jpeg 600w 200h 1x,
	face-600-200-at-2.jpeg 600w 200h 2x,
	face-icon.png 200w 200h">

Конечно, это можно — и нужно — улучшить. Дело не только в эстетике. Если синтаксис странный, его будут использовать неправильно. Как написал доктор Реми, «Хотелось бы, чтобы вебмастерам пришлось учить другой микросинтаксис. Тут не та ситуация, что была с проблемами из-за браузерных префиксов.»

Вторая проблема в том, что разработчики не хотят лишиться контроля. Есть проблемы, связанные с художественным замыслом (см. раздел под заголовком «Учитываю ли я художественный замысел?»), и многих не убеждает, что предложение Эпла решает их, хотя сторонники srcset как раз убеждены, что он учитывает все те случаи.

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

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

Так что подключайтесь. Читайте обсуждения и вносите свою лепту. А как только пыль уляжется и спецификация устаканится, мы, доктора, поставим окончательный диагноз.

Оригинал статьи и автор

Обычно на такие претензии возражают, что это вопрос философский, использовать или не использовать, тем более что кому какая разница, если в данный момент функция работает и не вызывает проблем в несовместимых браузерах. Этот аргумент вполне годится для некоторых случаев, когда дело касается незначительных ни на что не влияющих украшений, для которых не существует альтернативы, прописанной в стандартах. К примеру, я сама использовала ::-webkit-scrollbar. Но к рассматриваемому вопросу это не относится. У нас в стандартах есть альтернатива вот уже 11 лет под названием SVG. И если вы дадите ей шанс, она может справиться не только с маскированием текста, но и с многим другим.

Вот пример наложения текстуры на текст с использованием SVG:

Благодаря исправлениям от @devongovett код стал проще и компактнее.

Да, синтаксис может и более громоздкий, но зато это работает в гораздо более широком спектре браузеров: Chrome, Safari, Firefox, IE9, Opera. К тому же, довольно просто написать скрипт, который бы генерировал SVG код из заголовков и к каждому применял бы нужные величины. А когда в WebKit внесут исправление вот этого бага, можно будет вообще вынести шаблон SVG в отдельный файл и лишь ссылаться на него.

В том случае, если вас беспокоит семантика кода, скажу, что элемент <svg> считается потоковым содержимым и следовательно может использоваться в заголовках. Но даже если поисковая система не понимает строчный SVG, она просто проигнорирует все теги и всё равно увидит содержимое внутри элемента <text>. Имея это в виду, можно даже обеспечить нормальный просмотр в IE8, включив HTML5 исправление для <svg> элемента. Тогда CSS правила всё равно будут применяться к тексту. Нужно будет только добавить проверку и убирать теги <image>, т.к. IE8 показывает на их месте знак ошибки загрузки изображения (не все знают, но в HTML <image> и <img> эквивалентны, поэтому IE8 трактует их одинаково).

Перевод статьи Text masking — The standards way автор Lea Verou

Стандартный код трансформации-вращения, учитывая основные браузеры, выглядит следующим образом:

.example {
    -webkit-transform: rotate(360deg);
    -moz-transform: rotate(360deg);
    -o-transform: rotate(360deg);
    -ms-transform: rotate(360deg);
    transform: rotate(360deg);
}

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

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

Градианы (grad)

Градианы (также встречаются как грады и гоны) в коде сокращаются до “grad” . Полный круг состоит из 400 град, что является эквивалентом 360 градусам. Таким образом, если переписать код с использованием градиан – получим следущее (вендорные префиксы опущены для этого и всех следующих примеров)

.example {
	transform: rotate(400grad);
}

Так как 400 – это красивое круглое число, возможно экспериментировать с этой величиной станет для Вас проще и, как результат, ускорит все производимые вычисления.

Радианы (rad)

Радианы или rad записываются следующим образом:

.example {
	transform: rotate(6.2831853rad);
}

Полный круг состоит из 2π радиан. Как Вы знаете, число π равняется 3. 14, или, если быть более точным, 3.14159265, что в свою очередь равняется половине окружности с точки зрения радиан. Таким образом, чтобы получить полный круг, мы удваиваем это значение и получаем 6.2831853 радиан, т.е. целый круг.

Следовательно, 6.2831853rad = 400grad = 360deg. Как Вы можете убедиться работать с радианами не так удобно как с градами или даже с градусами.

Обороты (turn)

Единицы измерения "turn" (обороты) соответствуют своему названию. Один полный оборот. Таким образом, эквивалент того, что мы делали ранее в оборотах будет выглядеть так:

.example {
	transform: rotate(1turn);
}

Это, пожалуй, самая интуитивно понятная величина, так как она равняется одному полному обороту.

Поддержка браузерами?

Все эти альтернативные единицы измерения (включая градусы) являются частью CSS-данных типа "угол".

Как показали мои эксперименты с последними стабильными версиями таких браузеров как Chrome, Safari, и Opera – все они поддерживают эти единицы измерения. Firefox поддерживает радианы и градианы, но не поддерживает обороты. А вот Internet Explorer (тестировалось в IE10 PP2) не поддерживает ни одну из трех единиц измерения.

Примечание: Как было уже отмечено в комментариях, последнее обновление IE10PP добавило полную поддержку данных единиц измерения, также как и в случае с aurora build для Firefox.

Я создал демо-страницу с вращающимися блоками, которые приводятся в движение при наведении на них курсора, используя все три альтернативные единицы.

ДЕМО-СТРАНИЦА

Оригинал статьи и автор

Я полагаю, многие верстальщики уже догадались – о чём идёт речь, а если нет, то перед тем, как переходить к решению Ильи, давайте немного освежим память и вкратце рассмотрим несколько известных методов, а так же их достоинства и недостатки.

Я решил, что все способы следует рассматривать сразу на маленьком, но боевом примере.

Условие задачи

Есть две колонки. Левая с float:left имеет фиксированные ширину и высоту. Нужно, чтобы правая тянулась на всю оставшеюся ширину. При этом необходимо, чтобы из той же правой колонки не "вываливались" margin-ы элементов, а элементы с float: left или right не схлопывали высоту контейнера, и чтобы края колонки не обрезали элементы, которые из неё вылезают.

В общем, в результате должно получится что-то нечто похожее на следующий пример:

Решения

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

Перед тем, как переходить к первому варианту, предлагаю сразу посмотреть структуру HTML и часть CSS, которые во всех примерах будут абсолютно одинаковыми. Единственное что будет меняться в HTML - это классы у правой колонки (в зависимости от способа), а в CSS только лишь та часть, которая относится к методу.

<div class="left">
	<h2>Левый float</h2>
</div>
<div class="clearfix">
	<div class="date">12.05.2012</div>
	<h2>Заголовок</h2>
	<p>Ниже идёт картинка с float:left</p>
	<img src="img.jpg" class="float-left">
	<p class="clear-both">А у этого абзаца стоит clear:both;</p>
	<div class="absolute">Absolute</div>
</div>

/* Общие стили */
.left {
	float: left;
	width: 200px;
	background: #FC6;
	height: 200px;
	position: relative;
	z-index: 1;
}

h2 { margin-top: 10px;}
.float-left { float: left;}
.clear-both {
	font-size: 15px;
	clear: both;
	background: #F99;
}
.date {
	font-size: 20px;
	float: right;
	background: #FC0;
	padding: 2px 5px;
	margin: -10px -5px 0 0;
}
.absolute {
	position: absolute;
	bottom: -25px;
	right: 10px;
	width: 50px;
	height: 50px;
	background: white;
	border: 2px solid black;
}

clearfix

Для первого эксперимента возьмём один из самых популярных clearfix-ов, который в своё время доработал Chris Coyier, отказавшись от ненужного свойства font-size, в связи с пустым свойством content. Выглядит он так:

.clearfix:after {
	visibility: hidden;
	display: block;
	content: "";
	clear: both;
	height: 0;
	}
* html .clearfix             { zoom: 1; } /* IE6 */
*:first-child+html .clearfix { zoom: 1; } /* IE7 */

Я применил этот код к правой колонке, добавив ещё несколько свойств чисто для оформления. И вот что у нас получилось:

Как виндно по рисунку, из плюсов можно выделить только то, что благодаря clearfix-у правый нижний блок с position: absolute остался целым и невридимым и его вылезающая из колонки часть не образелась.

Ну, а в остальном, к сожалению, одни минусы. Их настолько много, что я даже сделал список:

• Верхние margin-ы у заголовка выпали из контейнера.
• Левый padding в контейнере провалился под левую колонку и больше не является отступом между элементами в правой колонке и левой с float: left. Оно и понятно, ведь clearfix не создаёт свой собственный контекст, поэтому блочная часть правой колонки фактически оказывается под левой, обтекая её своими инлайновыми боксами.
• Ну и самое печальное тут то, что последний абзац с clear:both оказался под левой колонкой, растягивая собой правую по высоте. Это опять же из-за того, что левая колонка и плавающая картинка в правой колонке остались в одном и том же контексте форматирования, поэтому clear реагирует и на то, и на другое.

Делаем вывод, что этот метод хорошо использовать только тогда, когда нам нужно просто очистить поток, чтобы контейнер чувствовал высоту своих потомков с float, и когда мы точно знаем, что в задаче не будет всех тех особенностей, из-за которых могут случиться вышеперечисленные проблемы.

overflow: hidden или auto

Ещё один, более достойный и простой способ, на мой взгляд, заключается в том, чтобы повесить на контейнер свойство overflow со значениями hidden или auto, благодаря которым мы создадим новый контекст форматирования и тем самым сможем изолировать наш блок – колонку от внешнего контекста.

Во-первых, в самой структуре мы лишь поменяем класс у правой колонки с class="clearfix" на class="overflow", а во-вторых, изменим наш CSS в пользу текущего метода.

/* метод с overflow */
.overflow {
	padding: 0 10px;
	background: #E76D13;
	position: relative;

	/* overflow */
	overflow: hidden;
}

* html .overflow { zoom: 1; } /* IE6 */
*:first-child+html .overflow { zoom: 1; } /* IE7 */

И вот, что у нас вышло:

На вид этот способ явно лучше предыдущего, за исключением того, что вылезающие за края элементы – обрезаются. Дело в том, что overflow: hidden устроен так, что выходящие за края блока элементы – попросту обрезаются, а со значением auto вообще появляется скроллинг. Этот нюанс порой доставляет массу неудобств, заставляя отказываться от этого метода в пользу других. 

Вывод такой, что для нашей задачи этот вариант не годится, поэтому идем дальше.

display:table

В эпоху быстро-уходящих на покой IE6-7 актуальными становятся свойства и значения, которые не имели поодержки в этих недобраузерах. И одна из таких "парочек" имеет название display: table и так же может являться ещё одним методом для решения нашей задачи. display: table, как и overflow: hidden вешается на контейнер, но работает немного иначе.

По традиции причешем наш код…

/* метод с display: table */
.table  {
	padding: 0 10px;
	background: #E76D13;
	position: relative;

	/* display: table */
	display: table;
}

* html .table  { zoom: 1; } /* IE6 */
*:first-child+html .table  { zoom: 1; } /* IE7 */

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

Так же, как и overflow: hidden display: table создаёт свой собственный контекст форматирования, изолирует контейнер, и мало того, в отличии от overflow: hidden, избегает проблем с обрезанием вылезающих элементов.

Но, проблема всё же есть, и она кроется в том, что элементы с этим свойством (в нашем случае – это правая колонка) ужимаются по содержимому и поэтому не растягивают контейнер на всю оставшуюся ширину. 

Так что, к сожалению, это решение нам тоже не подходит, поэтому пора переходить к самому вкусному!

Метод Ильи Стрельцына

Вот, наконец, мы и добрались до самого главного способа, который основан на предыдущем варианте с display:table, но имеет очень важное дополнение, которое и делает этот метод полностью рабочим.

Для начала сразу же приведу код, а уже после просмотра результата объясню в чём вся соль.

/* метод Ильи Стрельцына */
.table  {
	padding: 0 10px;
	background: #E76D13;
	position: relative;

	/* display: table */
	display: table;
}
/* Очень важное дополнение! */
.table:after {
	content: '. .';
	display: block;
	word-spacing: 99in;
	height: 0;
	overflow: hidden;
}

И, соответственно, результат:

На изображении можно увидеть, что все перечисленные в задаче пункты – выполнены и задача решена полностью. Правая колонка тянется на оставшуюся ширину, margin-ы элементов не вываливаются наружу, высота контейнера не схлопывается по высоте, и даже выпирающие элементы не обрезаются! В чём же подвох?

На самом деле в решении этой задачи нам помогает тот же трюк с псевдоэлементом, который помогал выравнивать блоки по резиновой сетке в этой статье. Весь приём заключается в двух свойствах и их значениях – это content: '. .'; и word-spacing: 99in;. Обратите внимание на две текстовые точки в свойстве content и на значение у word-spacing (99in), которое можно пересчитать в 9504px (с эстетической точки зрения 99in выглядят всё же красивее=)). Но давайте разберёмся более детально.

В общем, по спецификации, для таких вещей, как таблицы, ширина считается по алгоритму shrink-to-fit. Кратко объяснить его суть можно так. Вначале браузер "спрашивает" у контента, сколько бы ему хотелось иметь ширины, чтоб вольготно раскинуться в одну строку, не ломая строки переносами. Если ширина, "запрошенная" контентом, меньше доступной ширины контейнера — именно эта "запрошенная" ширина назначается нашему элементу. Если же нет — назначается такая ширина, чтобы элемент вплотную вписался в доступную ширину контейнера, а контенту волей-неволей приходится втискиваться в эту ширину, перенося строки.

В нашем случае текст псевдоэлемента (те самые 2 точки с пробелом между ними) "запрашивает" почти 10 тыс. пикселей — обычная ширина двух точек с пробелом плюс 9504 пикселей, на которые этот пробел увеличен благодаря word-spacing'у. То есть в любых реальных условиях этот контент никогда не сможет уместиться в одну строку, и браузеру всегда придется считать ширину нашей таблицы по второму варианту — по контейнеру. А ведь именно этого мы и добивались!

Заключение

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

Эта статья была обновлена 14 октября 2010, чтоб отобразить изменения в спецификации.

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

HTML5-элемент <audio>

Одно из самых волнующих и долгожданных свойств HTML5 – элемент <audio>, позволяющий нативно воспроизводить аудио в браузере. Мы уже можем ощутить преимущества его использования, так как практически все основные браузеры поддерживают его – на данный момент Firefox, Chrome, Safari и Opera, а скоро к ним присоединится и Internet Explorer 9, который сейчас на этапе беты (прим. пер.: уже давно релиз). В браузерах, которые не поддерживают <audio> нативно, мы легко можем использовать Flash.

Согласно спецификации

На сегодняшний день в спецификации есть определения пяти атрибутов для элемента <audio>:

1. src - валидный URL, указывающий источник контента 
2. autoplay - булевый атрибут, указывающий, должен ли файл воспроизводиться сразу же
3. loop - булевый атрибут, указывающий, должен ли файл воспроизводиться повторно
4. controls - булевый атрибут, указывающий, должен ли браузер отображать свои стандартные медиа-контролы
5. preload - none / metadata / auto - где metadata значит, что нужно предварительно загрузить только метаданные, а auto оставляет решение, загружать ли весь файл, за браузером.

Учтите, что preload заменил autobuffer в последней версии HTML5 спецификации. Раньше autobuffer содержал булево значение, указывающее, должен ли файл буферизироваться заранее. Теперь браузеры переходят с autobuffer на preload, так что мы рекомендуем пока использовать оба эти атрибута.

Кстати, это те же атрибуты, что и для элемента <video>.

Примеры

Давайте возьмем пару этих атрибутов и создадим простой пример, который будет воспроизводить аудиофайл:

<audio src="elvis.ogg" controls preload="auto" autobuffer></audio>

(Этот пример будет работать в последних версиях Firefox, Chrome и Opera. Чтоб он заработал в Safari, вам нужно заменить OGG-файл на MP3)

Конечно, спецификация еще не закончена, а также не достигнут консенсус, какой кодек поддерживать. В этой таблице представлены кодеки, которые поддерживаются современными браузерами:

Чтобы создать собственные контролы, мы можем воспользоваться API-методами, описанными в спецификации:

• play ( ) – воспроизводит аудио
• pause ( ) - приостанавливает аудио
• canPlayType ( ) – запрашивает, чтоб браузер определил, может ли воспроизводиться данный mime-тип
• buffered ( ) – атрибут, который указывает время начала и конца буферизированной части файла

Используйте <source>

Наилучший способ заставить браузер воспроизводить аудио (или видео, если на то пошло) – это использовать элемент <source>. Браузер будет пытаться загрузить первый источник аудио, а если у него не получится или если он не поддерживает, браузер перейдет к следующему источнику аудио. Помимо этого, мы легко можем установить Flash-плейер, если больше ничего не помогает:

<audio controls preload="auto" autobuffer>
  <source="elvis.mp3" />
  <source="elvis.ogg" />
  <!-- а теперь flash-вариант -->
</audio>

Однако, предупреждаем: обращайте внимание на порядок элементов <source>. На момент написания, сообщались проблемы с Mobile Safari и ранними версиями Firefox.

Кросс-браузерная реализация

Когда мы создавали jPlayer, аудио-плагин для jQuery, мы пытались побороть некоторые ограничения большинства аудио-плейеров на основе Flash. Многие используют Flash для разработки графического интерфейса плейера, эффективно изолируя его от процесса веб-дизайна.

Первоначальный jPlayer использовал Flash непосредственно для воспроизведения аудио, при этом стиль можно было задавать при помощи HTML и CSS. С увеличением поддержки HTML5 современными браузерами мы решили избавиться от Flash-зависимости и использовать нативное аудио в тех случаях, когда оно поддерживается.

Самой значимой проблемой является кросс-браузерная реализация, так как отсутствие общепринятого браузерами аудиоформата вызывает сложности. Если разработчики хотят в полной мере использовать преимущества всех браузеров, которые поддерживают HTML5 <audio>, им будет необходимо создавать обе версии аудиофайла, который они хотят воспроизводить – MP3 и Ogg (а также WAV в случае с Opera).

Так как HTML5-стандарт все еще находится в процессе разработки (прим. пер.: текущее состояние спецификации – ready for first implementations), несколько аспектов элемента <audio> отличаются от браузера к браузеру. Например, судя по всему, не существует способа определить прогресс загрузки аудиофайла во всех браузерах, потому что это предполагает использование DOM-атрибута buffered. Chrome поддерживает buffered, в Safari он есть, но ведет себя несколько иначе, а текущие версии Opera и Firefox его не поддерживают (хотя поддерживает Firefox 4 beta).

Хоть эти несоответствия и не являются накладками, с целью эффективной конкуренции с решениями, основанными на плагинах, имплементация HTML5 <audio> должна быть последовательной во всех браузерах и соответствовать текущим требованиям в будущем.

JavaScript-решения

Если мы стремимся получить преимущества от способностей каждого браузера воспроизводить аудио, нам нужно создать разные решения для разных браузеров. Мы можем определять браузер пользователя, но учитывая стремительное развитие информационных технологий, лучше выяснить, какие возможности поддерживает конкретный браузер, и приспособиться соответственно.

Для демонстрации этого мы создали жесткую и готовую к использованию HTML5-аудио проверку.

Используя JavaScript, вы можете проверить, поддерживается ли тег <audio>:

// возвращает булевский атрибут
var
 audioTagSupport =
!!(document.createElement('audio').canPlayType);

или проверить совместимость с типом файла:

// Нужно сначала проверить canPlayType или исключение
  // будет выброшен для тех браузеров, которые его не поддерживают

  var myAudio = document.createElement('audio');

  if (myAudio.canPlayType) {

    // На данный момент canPlayType(type) возвращает: "", "maybe" или "probably"

    var canPlayMp3 = !!myAudio.canPlayType && "" !=myAudio.canPlayType('audio/mpeg');
    var canPlayOgg = !!myAudio.canPlayType && "" !=myAudio.canPlayType('audio/ogg; codecs="vorbis"');
  } 

Учтите, что для того чтобы изменить атрибут src объекта audio или элемента вам необходимо пересоздать этот объект или элемент с новым значением атрибута src или изменить URL атрибута src и выполнить команду myAudio.load.

Таким образом, для создания решения, которое полностью использует преимущества HTML5 аудио, вам, как правило, необходимо:

1. проверить поддерживается ли HTML5 <audio> и, если нет, использовать Flash,
2. проверить уровень поддержки HTML5 <audio> и адаптировать свой код соответственно для каждого браузера,
3. проверить, какие типы файлов поддерживаются, и привязать необходимые форматы файлов.

Предстоящий путь

Несмотря на то, что HTML5 аудио – это относительно сырой компонент стандарта, если будут развиваться текущие тенденции и пользователи будут использовать последние версии Safari, Firefox, Chrome и Opera, поддержка браузеров может достичь 30%. Это значительная доля рынка браузеров, которым впредь не нужно будет зависеть от Adobe Flash, Microsoft Silverlight или других плагинов для поддержки аудио. Добавьте к этому факт, что Internet Explorer 9 поддерживает HTML5 <audio>, и мы в скором времени увидим, что большинство установленных браузеров также станут поддерживать его.

И когда мобильные и другие малогабаритные устройства, такие как планшеты, начнут поддерживать HTML5 аудио, вы убедитесь, какой важной становится нативная поддержка аудио.

Полезные ссылки

• [whatwg] Кодеки для <audio> и <video>
• Какие браузеры поддерживают HTML5 <audio> в Windows сегодня?

Оригинал статьи и автор

Мы привыкли думать, что для изменения размеров тескта достаточно указать значение относительно размеров базового шрифта, используя em’ы или проценты. В адаптивном web-дизайне мы пишем кучу правил и устанавливаем кучу ограничений, чтобы удостовериться, что наш лейаут хорошо отображается на различных разрешениях. Текст – это замечательная изменчивая среда, но, указав один размер не получится красиво заполнить им страницу. Мы рассмотрим несколько простых советов как добиться того, чтобы текст красиво заполнял лейаут, невзирая на размер экрана или устройство на котором он отображается.

Конечно, это слишком обширная тема, чтобы раскрыть ее в одном уроке. Поэтому в конце перечислено несколько полезных ресурсов на эту тему.

Заставляем типорграфику масштабироваться

Ах, этот адаптивный web-дизайн! Эти прекрасные резиновые сетки и медиа-запросы (media queries), которые помогают нашим дизайнам заполнять экраны любых размеров. К счастью для нас текст может масштабироваться практически безгранично и заполнять любой контейнер, в который мы его поместим. Наврядли нам нужно что-то еще придумывать для наших адаптивных дизайнов… или нужно? В идеале, когда наш основной лейаут масштабируется, то же должен делать и текст, и вот один способ как этого добиться.

Наша тестовая страница

Для нужд этого примера я приготовил очень простую страницу, которая использует для демонстрации несколько первых абзацев из произведения “Алиса в Стране чудес” в качестве рыбы. Ваш сайт, надеюсь, представляет из себя нечто большее, но простота этой страницы идеально подходит нам для наших тестов, а эта техника может быть применена и к более сложным страницам.

Давайте взглянем на наш исходник и посмотрим, что у него под капотом. <h1> в качестве заголовка и несколько параграфов, обернутых в <div>, которому назначен класс wrap. Мы используем этот контейнер для управления длиной строки в нашем примере. Для вашего сайта ширина контейнера будет основываться на вашей сетке и ее адаптивном поведении, но идея остается неизменной.

Быстрое погружение в CSS расскажет нам, что мы установили размер шрифта у body в 100% (что, для справки, составляет около 16px). Размеры остальных елементов задаются при момощи em. Замечательно! Мы взяли хороший старт:

body {
    font-size: 100%;
    line-height: 1.6875;
    font-family: Georgia;
}

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

Сначала проверяем наименьший экран

Давайте начнем смотреть на нашу разметку на экране очень маленькой ширины, допустим что-то около 320 пикселей по ширине. примерно это вы увидите на большинстве популярных мобильных устройствах.

Изначально, при такой малой ширине ширина строки будет немного меньше чем общепринятая оптимальная длина в 45 – 75 символов. Или, если вы не фанат подсчета количества символов в строке, вы можете заметить, что строки кажутся короткими и за текстом трудновато следить. Лично я, как правило, часто перечитываю строку по несколько раз.

Чтобы получить немного больше места для комфортной длины строки мы можем уменьшить общий размер шрифта, или мы можем сделать больше наш контейнер. Раз уж мы говорим тут о масштабировании текста, то я предпочту остановиться на первом варианте, но и второй вариант тоже довольно приемлем.

Чтобы справиться с ситуацией, давайте напишем медиа-запрос для максимальной ширины в 400 пикселей. Да, это не 320 пикселей, но я предпочитаю устанавливать ограничения там где дизайн в них действительно нуждается, а не основываясь на размерах экранов у устройств.

Самый простой способ сменить размер всех шрифтов — сменить font-size у

:

@media only screen and (max-width: 400px) {
    body {
        font-size: 90%;
    }
}

Благодяря тому факту, что мы изначально указали размеры шрифтов в em, мы можем сменить все размеры на странице, просто исправив одну строчку кода. Слава относительным размерам шрифта!

Движемся дальше

Если мы сделаем так как делают web-дизайеры и продолжим увеличивать окно браузера до огромных размеров, наш контейнер с текстом начнет становиться все больше и больше и текст в нем будет перерисовываться так, чтобы заполнить его целиком. Все так как мы и ожидаем. Но проследите за длиной строки. Когда пояляется ощущение, что она слишком длинная?

Примерно при ширине 800 пикселей (ширина всего окна браузера) длина строки становится некомфортно длинной. Похоже пришло время добавить еще одно ограничение для нашего текста.

@media only screen and (max-width: 800px) {
    body {
        font-size:100%;
    }
}

@media only screen and (max-width: 1100px) {
    body {
        font-size: 120%;
    }
}

Вот как теперь выглядин наша страничка при любой ширине окна между 800 и 1100 пикселями. Мы получили немного больше рабочего места и наш текст заполняет его немного более красиво.

В этот раз мы написали два медиа-запроса. Один для максимальной ширины 800px с font-size у body. установленным в 100%, который покрывает диапазон размеров окна между 500px и 800px. И второй, для тех случаев, когда ширина окна больше 800px, и позволяет нам увеличить базовый размер шрифта.

увеличил базовый размер шрифта до 120% когда мы проходим отметку в 800 пикселей, чтобы получить длину строки примерно такую, какая мне нравится. Конечно это всего лишь мои ощущения, которые зависят от контента как такового и от окружающих элементов. Выбирайте граничные точки и изменения масштаба, которые имеют смысл для вас и вашего дизайна. Главная цель – достичь комфортного чтения и сбалансированной сетки. Тестирование ваших лейаутов не только изменяя размеры окна браузера, поможет достичь наилучших результатов.

Иии… полетели!

Догадайтесь, что будет дальше, я собираюсь продолжить растягивать окно браузера шире и шире и посмотрю что произойдет. Неудивительно, что длина строки снова растет и достигает неудобных размеров примерно при ширине в 1100px. Пришло время для еще одной граничной точки? Мы можем продолжить добавлять и добавлять точки сколько угодно, но, кажется, это не очень умно, этому уже не видно конца!

Технически, вы можете продолжать масштабирование бесконечно. Однако, скорее всего, ваш макет и изображения этого не могут. В какой-то момент нам надо будет остановиться. И для этого простенького демо я решил остановиться на 1100 пикселях.

Осталось дописать последний медиа-запрос. Я хочу, чтобы что-то останавливало нашу строку от дальнейшего роста, чтобы мы могли все застыло на том моменте когда мы имеем приемлемую длину строки. Самы легкий путь сделать это — добавить максимальную ширину диву, содержащему текст.

Для начала, нам надо определить приблизительную ширину нашего дива с содержимым. Если ширина окна браузера равна 1100 пикселям, а ширина дива-обертки равна 70%, то совсем чуть-чуть математики дас нам 770 пикселей (1100 * 0.7).

Вооруженные этой информацией отредактируем наш последний медиа-запрос:

@media only screen and (min-width: 1100px) {
    body {
        font-size: 120%;
    }

    .wrap {
        max-width: 770px;
    }
}

Шрифт в нашем демо теперь такого размера, какой мы захотели.

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

Суммируя все воедино

Даже из такого простого примера вам должно быть ясно, что вы должны быть аккуратны при выборе когда ставить ограничения для шрифта при контроле длины строки. А что же тогда на счет интерлиньяжа и иерархии? На них так же влияет изменение размеров текста и контейнера. Есть еще так много тем для изучения!

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

Дальнейшее чтение

Это простенькое демо только вершина айсберга. Если типографика для адаптивного web-дизайна вас заинтересовала, то вот несколько рекомендаций по чтению:

• Тим Браун (Tim Brown) делает замечательную работу, собирая техники и вещи, о которых можно задуматься применительно к web-типографике.
• Есть не только проценты и em’ы, когда разговор заходит об изменении размеров текста в web. Итан Маркотт (Ethan Markotte) рассказывает об этом подробней в блоге Typekit.
• Тяжело говорить о типографике не вдаваясь в дискуссии по поводу вертикального ритма. Эта классическая статья на 24 ways рассказывает об этом подробней (И не пропустите урок Мэта Уилкокса (Matt Wilcox) о сохранении вертикального ритма при помощи CSS и jQuery).
• И, наконец, взгляните на урок Пола Роберта Ллойда (Paul Robert Lloyd) о том как построить адаптивный сайт за неделю. Сегодняшняя 2 часть об адаптивной типографике и сетках

Перевод статьи Handling typography for responsive design автора Val Head

В эксперименте Романа он использует абсолютно позиционированные псевдоэлементы чтобы прикрыть тени (которые сформированы радиальным градиентом в качестве фона). Он воспользовался тем фактом, что когда вы прокручиваете скроллируемый контейнер, его бэкграунд не прокручивается вместе с ним, но, при этом, абсолютно позиционированные элементы внутри контейнера прокручиваются. Таким образом, когда вы проскролливаете содержимое блока, тень становится видно из-под псевдоэлемента. Более того, эти псевдоэлементы представляют собой линейный градиент от белого к прозрачному, что позволяет теням проявляться постепенно.

Когда я увидела демо Романа, мне стало интересно возможно ли добиться того же эффекта без дополнительных контейнеров (включая псевдоэлементы). И, похоже, это идеальный случай для использования background-attachment: local. На самом деле, это был единственный реальный вариант использования этого правила, который я когда либо видела.

«background-attachment… что? Я знаю только scroll и fixed!»

scroll и fixed были единственными значениями для background-attachment во времена CSS 2.1. scroll — это дефолтное значение, которое позиционирует фоновое изображение относительно элемента, которому оно назначено, в то время как fixed позиционирует его относительно области просмотра (viewport), в результате чего бекграунд остается на месте, в то время когда страница прокручивается. Как результат этих определений, в случае если скроллируемой была только часть страницы (например, <div> с overflow: auto), его бекграунд не прокручивался когда прокручивался сам контейнер.

В модуле CSS, посвященному границам и фоновым изображениям Backgrounds & Borders Level 3 было добавлено новое значение, чтобы снять это ограничение: local. Когда применяется background-attachment: local фоновое изображение позиционируется относительно содержимого элемента. В результате этого оно прокручивается когда прокручивается элемент. Это не новая фича, она была нам доступна со времен первых черновиков Backgrounds & Borders 3 в 2005 году (конечно, реализация заняла некоторое время, так что можно считать, что с 2009).

Если вам все еще не понятно как это работает, поиграйте немного с этим кодом, который демонстрирует работу всех трех значений (естественно ваш браузер должен поддерживать все три):

«Хорошо, я понял. Вернитесь к скроллируемым теням пожалуйста?»

Основная идея заключалась в том, чтобы превратить эти абсолютно позиционированные псевдоэлемнты в фоновые слои, к которым применено правило background-attachment: local. Я попробовала это, это сработало и помогло довольно сильно сократить код. Вот как выглядит CSS:

Недостаток этого подхода в том, что мы немного понижаем кроссбраузерность. Оригинальный эксперимент Романа мог работать даже в IE8, если заменить градиенты картинками (градиенты не влияют на функциональность). Когда вы полагаетесь на background-attachment: local, вы сужаете поддержку браузерами до IE9+, Safari 5+, Chrome и Opera. Firefox оказался самым явным прогульщиком из этого списка, вы можете проголосовать за баг #483446, если вы заинтересованны в том, чтобы они реализовали это.

Тем не менее, поддержка браузерами не очень важна, т.к. эффект очень изящно деградирует. В браузерах, не поддерживающих этот метод, вы просто не увидите теней

Перевод статьи Pure CSS scrolling shadows with background-attachment: local автор Lea Verou

Почему это так классно?

На это есть несколько причин.Вот две:

• Есть такая вещь как комфортная длина строки для чтения текста с экрана. Не хочу ворошить осиное гнездо, но давайте предположим, что это 80 символов. Так вот, эти значения позволяют сохранить ощущение идеальной ширины строки на экране любого размера.
• Они позволят вам тесно связать между собой размер, скажем, типографского заголовка и контента. который следует за ним. Например, как в классической статье в блоге Трента Уолтона (Trent Walton).

Как они работают

Одна единица любого из трех значений равняется 1% от расмера оси области просмотра. Область просмотра == ширина окна браузера == объект window. Если ширина области просмотра 40см, то 1vw = 0.4см.

При использовании font-size мы предполагаем, что ширина одной буквы равна значению font-size, но, как мы знаем, в шрифтах, которые не являются моноширинными, ширина буквы может быть довольно произвольной. Поэтому нам приходится немного играться со значениями, чтобы подобрать нужное. Что мы, собственно, и делаем, правда?

1vw = 1% от ширины области просмотра
1vh = 1% от высоты области просмотра
1vmin = 1vw или 1vh, берется наименьшее значение

Как их использовать

Да как два пальца:

h1 {
    font-size: 5.9vw;
}

h2 {
    font-size: 3.0vh;
}

p {
    font-size: 2vmin;
}

Демо

Вот видео простой разметки, использующей единицы vw для нудж типографики:

Посмотрите демо и обратите внимание на поддержку браузерами.

Баги!

Поддержка будет в Chrome 20, но есть один существенный недостаток. Когда ресайзится окно браузера шрифт не изменяется в зависимости от размеров области просмотра. В спеке сказано:

Когда высота или ширина области просмотра изменяется, размеры изменяются соответсвенно.

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

Чтобы побороть проблему (позволить шрифту менять размеры без перезагрузки страницы) нам нужно как-то перерендерить элемент. Я использовал jQuery и просто поигрался со значением z-index каждого элемента (которое, в данном, случае ни на что не влияет), смена z-index заставляет браузер перерисовать элемент.

causeRepaintsOn = $("h1, h2, h3, p");

$(window).resize(function() {
    causeRepaintsOn.css("z-index", 1);
});

Поддержка браузерами

Chrome 20+ и IE 10+.

Я попробовал применить значения в Opera Next (12), Safari 5.2 и Firefox Beta (13) и мне не свезло.

Не только font-size

Для справки, это эти новые значения, просто еще одни единицы. Такие же как em, px и т.п. Вы можете использовать их не только для указания размера шрифта.

Я подумал о размере шрифта как о наиболее интересном варианте использования, в свете того, что такие вещи как margin, padding и width и так могут реагировать на размеры окна, если указать им значения в %. Возможно, бывают такие случаи когда, каким-либо, глубоко вложенным элементам нужно будет отсчитывать ширину не относительно своего родителя, а относительно ширины окна.

Используем это сейчас

Нативное использование

Вам нужно использовать деградацию:

h1 {
    font-size: 36px; /* Некое резервное значение, которое не выглядит ужасным */
    font-size: 5.4vw;
}

Тест на поддержку

В Modernizr пока нет проверки на поддержку этих значений, но вы можете написать проверку самостоятельно, используя некий временный элемент, которому установлена некая приближенная ширина в CSS, которая потом переустанавливается в JavaScript и проверяется, равна ли эта ширина ширине окна. Что-то типа:

var testEl = $("#vw-test");

var viewport = $(window);

testEl.css({
  width: "100vw"
});

if (testEl.width() == viewport.width()) {
   $("html").addClass("vw-support");
} else {
   $("html").append("vw-unsupported");
};

Похожий функционал в FixText.js

Мы обсуждаем идею привязки ширины текста заголовка к ширине окна — это как раз то, что реализует FixText.js. Только реализует он это через нетривиальный JavaScript, математику, спаны и т.п. Теоретически вы можете запустить проверку на поддержку и использовать Modernizr.load для загрузки FixText.js если проверка провалилась.

Собственно

Что вы думаете? Вам понравилось? Есть идеи как это можно использовать?

Перевод статьи Viewport Sized Typography автор Chris Coyier

• Используем разный <dl> для каждой пары: разметка доминирует над стилями, что плохо
• Float: не гибко
• display: run-in; для <dt>: плохая поддержка браузерами (не поддерживается в Firefox)
• Добавление <br> после каждого <dd> и установка термину и определению display: inline;: невалидная разметка. Нужно ли продолжать?

Ах, если бы добавление <br> было валидным… Или, даже так: что если бы мы могли вставлять <br> при помощи CSS? На самом деле мы можем!

Наверняка вы в курсе, что символы CR и LF которые представляют собой разрыв строки — это обычные unicode-символы, которые могут быть вставлены где угодно как и все остальные unicode-символы. Им соответствуют коды 000D и 000A соответсвенно. Это значит, что они тоже могут быть вставлены в генерируемый контент если их должным образом экранировать. Далее, мы можем использовать соответствующее значение white-space, чтобы заставить браузеры обращать внимание только на вставленные разрывы строк. Выглядит это вот так:

dd:after {
    content: '\A';
    white-space: pre;
}

Заметьте, что ничего из вышеперечисленного не относится к CSS3. Все это старый добрый CSS 2.1

Конечно если у вас есть несколько <dd> для каждого <dt>, то вам придется немного изменить код. Но в этом случае вам, скорее всего, не понадобится такое форматирование.

Добавлено: как заметил Кристиан Хейльман (Christian Heilmann), в HTML3(!) в элементах <dl> использовался атрибут compact, который, собственно, делал тоже самое. Сейчас в HTML5 он считается устаревшим, как и остальной фукнкционал представления в HTML.

Вот так выглядит финальный результат:

Протестировано в IE8, Chrome, Firefox 3+, Opera 10, Safari 4+.

Перевод статьи Flexible multiline definition lists with 2 lines of CSS 2.1 автор Lea Verou