UL LI:nth-child(3n+3) {
	    color:#CCC;
	    }

Что делает CSS-код, приведенный выше? Он выбирает каждый третий элемент внутри маркированного списка: это 3-й, 6-й, 9-й, 12-й и т.д. Давайте посмотрим, как именно работает это выражение и что еще можно сделать с помощью :nth-child.

Всё зависит от того, что находится между скобками. Селектор :nth-child принимает два ключевых слова: even и odd. Тут всё просто: even выбирает чётные элементы, такие как 2-ой, 4-ый, 6-ой и т.д., а odd выбирает нечётные элементы, такие как 1-й, 3-й, 5-й и т.д.

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

	UL LI:nth-child(5) {
	    color:#CCC;
	    }

Однако давайте вернемся к 3n+3 из первого примера. Как он работает и почему выбирается каждый третий элемент? Весь фокус в понимании переменной n и приведенного алгебраического уравнения. Подумайте об n, как о начинающемся с нуля множестве целых чисел. Потом дополните уравнение. Так 3n это 3×n, а все уравнение вместе это (3×n)+3. Теперь, подставляя вместо n числа больше или равные нулю, мы получим:

• (3 × 0) + 3 = 3 = 3-й элемент
• (3 × 1) + 3 = 6 = 6-й элемент
• (3 × 2) + 3 = 9 = 9-й элемент и т.д.

А как насчёт :nth-child(2n+1)?

• (2 × 0) + 1 = 1 = 1-й элемент
• (2 × 1) + 1 = 3 = 3-й элемент
• (2 × 2) + 1 = 5 = 5-й элемент и т.д.

Так, стоп! Это ведь то же самое, что и odd. Тогда, возможно, не стоит использовать это выражение? Но разве в этом случае мы не подвергаем наш первый пример излишнему усложнению? Что, если вместо 3n+3 мы запишем 3n+0 или ещё проще 3n?

• (3 × 0) = 0 = ничего нет
• (3 × 1) = 3 = 3-й элемент
• (3 × 2) = 6 = 6-й элемент
• (3 × 3) = 9 = 9-й элемент и т.д.

Итак, как вы можете видеть, результат получится такой же, а значит, нет необходимости в +3. Мы можем использовать и отрицательные значения n, с таким же успехом, как и вычитание в уравнениях. Например, 4n-1:

• (4 × 0) – 1 = –1 = ничего нет
• (4 × 1) – 1 = 3 = 3-й элемент
• (4 × 2) – 1 = 7 = 7-й элемент и т.д.

Использование -n может показаться странным — ведь если конечный результат отрицательный, то никакие элементы в выборку не попадут. Но если дополнить уравнение и снова сделать результат положительным, то выборка окажется довольно интересной: при помощи неё можно будет получить первые n элементов, например так: -n+3:

• –0 + 3 = 3 = 3-й элемент
• –1 + 3 = 2 = 2-й элемент
• –2 + 3 = 1 = 1-й элемент
• –3 + 3 = 0 = ничего нет и т.д.

На SitePoint есть хороший справочник с милой табличкой, которую я бесстыдно опубликую здесь:

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

Селектор :nth-child — один из немногих CSS-селекторов, который почти полностью поддерживается в современных браузерах и абсолютно не поддерживается в IE, даже в IE8. Поэтому когда дело доходит до его использования, и конечный результат сделан по технологии прогрессивного улучшения — вы можете смело использовать его для некоторых оформительских элементов, вроде расцветки строк таблицы. Однако не стоит применять его в более серьезных случаях. Например, полагаться на него в раскладке сайта или удалять правое поле из каждого третьего блока в сетке три на три, чтобы они вошли в ряд.

Спасением здесь может послужить библиотека jQuery, которая реализует поддержку всех CSS-селекторов, включая :nth-child, даже в Internet Explorer.

Всё равно неясно?

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

Также загляните на страничку полезных рецептов :nth-child, там вы сможете найти код для наиболее распространенных случаев.

Перевод оригинальной статьи «How nth-child Works» Криса Койера (Chris Coyier), опубликованной на сайте «CSS-Tricks».

Вкратце: производительность.

Как работает CSS

В связи с моей работой я делаю много тестов производительности. Для определения «узких мест» мы используем массу приложений. Например, Google Page Speed, который дает рекомендации по улучшению производительности JavaScript и рендеринга. Прежде чем я перейду к рассмотрению этих рекомендаций, нам нужно разобраться как браузеры работают с CSS

Стиль элемента применяется в момент его создания

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

Взгляните на этот документ:

	<body>
	    <div id="content">
	        <div class="module intro">
	            <p>Lorem Ipsum</p>
	        </div>
	        <div class="module">
	            <p>Lorem Ipsum</p>
	            <p>Lorem Ipsum</p>
	            <p>Lorem Ipsum <span>Test</span></p>
	        </div>
	    </div>
	</body>

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

Далее браузер видит элемент <div> со значением атрибута ID content. И снова в этот момент времени браузер считает его пустым. Он не рассматривает другие элементы. Как только браузер рассчитает стиль, элемент отображается на экране. Затем браузер определяет нужно ли перерисовать <body> — стал ли элемент шире или выше? Я подозреваю, что там есть масса других проверок, но изменение ширины и высоты — самый распространенный способ повлиять на отображение родительского узла.

Процесс продолжается, пока браузер не достигнет корневого узла документа.

Вот как выглядит визуализация процессов перерисовки в Firefox:

CSS селекторы анализируется справа налево

Чтобы определить, применяется ли CSS-правило к определенному элементу, браузер рассматривает селектор справа налево.

Если у вас есть селектор body div#content p { color: #003366; }, то, когда каждый элемент появляется на странице, браузер проверяет, является ли он параграфом. Если да, он начинает подниматься вверх по DOM и ищет <div> со значением атрибута ID равным content. Если он его находит, то продолжает подниматься по DOM пока не найдет <body>.

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

Правила

Возвращаясь к Page Speed, давайте рассмотрим несколько его рекомендаций:

• Избегайте селектора по потомку: .content .sidebar;
• Избегайте селектора по дочернему элементу: .content > .sidebar и селектора по следующему элементу: .content + .sidebar.

Конечно, селекторы по ID — самые быстрые. Проверить применимость селектора #content к рассматриваемому элементу можно очень быстро. Есть у него этот ID или нет? Селекторы по классу практически такие же быстрые, так как нет никаких связанных элементов, которые надо проверять.

Селекторы по потомкам, такие как .content .sidebar — более ресурсоемкие, так как, чтобы определить надо ли применять правило к .sidebar, браузер должен найти .content. Cелектор по дочернему элементу, например, .content > .sidebar, лучше селектора по потомку, так как браузер должен проверить только один элемент вместо множества.

К сожалению, селекторы + и > не поддерживаются IE6. Так что если его поддержка актуальна для вас, то про них придется забыть. Примечание переводчика.

Селектор по тегу и универсальный селектор

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

Рассмотрим следующий пример:

#content * { color: #039; }

Так как в селекторе присутствует ID, то можно подумать, что этот селектор обрабатывается очень быстро. Проблема в том, что браузер обрабатывает селектор справа налево и сперва проверяется универсальный селектор. Для того чтобы браузер мог определить, должен ли цвет текста элемента быть тёмно-синим, надо проверить каждый предок элемента, пока не будет найден предок с атрибутом ID равным content или не будет достигнут корень документа.

И это должно быть сделано для каждого элемента на странице.

Теперь, когда мы понимаем, как элемент обрабатывается, как определяется применимость правил к элементу, давайте рассмотрим пример.

Почему IE долго не поддерживал :last-child

Все жаловались: у всех браузеров, кроме IE, есть поддержка :last-child (она появилась только в IE9!) Некоторые могли подумать насколько же сложнее сделать :last-child, если уже реализован :first-child?

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

	.module > p:first-child { color: red; } /* Первое правило */
	.module > p:last-child { color: blue; } /* Второе правило */

Когда мы рассматриваем внутренности первого <div>, мы видим, что там есть параграф. Браузер видит что-то вроде этого:

	<div class="module">
	    <p>Lorem Ipsum</p>

Нужно ли применить первое правило к параграфу? Да, это параграф; да, это первый дочерний узел; и, да, это непосредственный потомок элемента с классом module.

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

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

Как на самом деле это делает браузер?

Я не мог сказать с абсолютной уверенностью, как браузеры парсят :last-child, так что я создал несколько тестов:

• Статическая HTML-страница;
• Рендеринг с паузами в одну секунду.

Первый пример весьма скучен. В любом браузере, включая IE9, всё отображается корректно. Внутри <div> первый элемент красный, а последний синий. Но посмотрите на второй пример, и вы увидите интересные отличия в поведении браузеров.

Второй пример приостанавливается перед добавлением каждого параграфа в <div>.

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

В Safari, Chrome и Opera мы увидим другой подход. Первый параграф красный. Второй отображается чёрным. Последний параграф отображается чёрным, пока браузер не получит закрывающий тег </div>. В этот момент последний параграф становится синим. Эти браузеры не рассматривают элемент как последний, пока не будет закрыт родительский.

В Internet Explorer 9 Beta я нашел интересный баг. В то время, как статическая страница отображается корректно, версия с паузами отрабатывает с любопытным побочным эффектом. Первый параграф синий, второй параграф синий и затем — третий. Когда закрывающий тег </div> загружен, предпоследний параграф меняет цвет на чёрный. IE9 пытается обрабатывать селектор как Webkit и Opera, но… м-м… не выходит. Надо бы отправить багрепорт в Microsoft.

Почему у нас нет селектора по родителю?

Уже дано достаточно пояснений, чтобы можно было вернуться к оригинальному вопросу. Проблема не в том, что у нас не может быть селектора по родителю. Проблема в том, что мы столкнемся с проблемами быстродействия, когда дело дойдет до определения того, какие CSS-правила применимы к данному элементу. Если Google Page Speed не рекомендует использование универсальных селекторов, то можно гарантировать, что селектор по родителю будет первым в списке ресурсоемких селекторов, намного опережая все проблемы с производительностью, которые могут быть вызваны использованием универсального селектора.

Давайте посмотрим почему. Первым делом давайте приведём пример синтаксиса для селектора по родителю.

div.module:has(span) { color: green; }

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

Посмотрите на часть нашего документа:

	<div class="module">
	    <p>Lorem Ipsum</p>
	    <p>Lorem Ipsum</p>
	    <p>Lorem Ipsum <span>Test</span></p>
	</div>

Исходя из того, что мы видим, .module будет отображён без использования правила, применяемого селектором по родителю. Когда будет загружен первый элемент <p>, нужно повторно оценить применимость селектора по родителю к <div>. Нужно сделать это снова для следующего параграфа. И снова, для следующего. Наконец, когда <span> загружен, селектор по родителю будет применен к родительскому <div>, и элемент нужно будет повторно перерисовать.

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

Почему проблему можно решить с помощью JavaScript?

Это только кажется, что JavaScript решает проблему. В общем случае JavaScript-заплатки (заплатки — polyfills — части кода, обеспечивающие функциональность, которую должен обеспечивать браузер. Примечание переводчика). Или регрессивное усовершенствование (или как там вы, молодежь, это сейчас называете) запускаются только один раз, после полной загрузки DOM.

Для того чтобы действительно имитировать поведение CSS, любой скрипт, решающий эту проблему, должен запускаться после отображения каждого элемента на странице, чтобы определить, нужно ли применить нашу «заплатку». Помните CSS-expressions в Internet Explorer? Именно по этой причине они вызывали такие проблемы с производительностью.

Не невозможно

Появится ли когда-нибудь селектор по родителю? Возможно. То, что я опиcал, не невозможно. На самом деле — наоборот. Это значит только то, что нам придётся иметь дело с ухудшением производительности из-за использования этого селектора.

Перевод оригинальной заметки «Why we don't have a parent selector» Джонатана Снука (Jonathan Snook), опубликованной в блоге «Snook.ca».

Вот что о нём написано в спецификации:

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

Спецификация WHATWG HTML5

Мы можем использовать <details> для создания «виджетов-аккордеонов», которые пользователь может разворачивать и сворачивать. Внутри этого элемента можно разместить любое содержимое.

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

Прежде чем мы продолжим, вам нужно учесть, что сейчас только Chrome поддерживает элемент <details>. Скоро к нему присоединится и Opera, но немного костылей нам все-таки понадобится. Что ж, запускайте Chrome, и давайте смотреть.

Использование <details>

Имеются два элемента: <details> и необязательный <summary>. Элемент <details> — это обёртка для содержимого, которое мы хотим показать и скрыть, а <summary> содержит описание и заголовок этой группы. Формально <summary> нам не нужен. В его отсутствие браузер подставит текст по умолчанию, например «details» в Chrome. Давайте взглянем на код:

	<details>
	    <summary>Покажи-скрой меня</summary>
	    <p>Бурное развитие внутреннего туризма привело Томаса Кука.</p>
	</details>

Вы можете посмотреть это в действии на jsbin. Даже этот простой пример прекрасно демонстрирует эффект переключения. Без JavaScript!

Атрибут open

В вышеприведенном примере содержимое скрыто при загрузке страницы. Мы можем сделать его видимым по умолчанию, добавив одиночный атрибут open для <details>, пример на jsbin:

	<details open>
	    <summary>Покажи-скрой меня</summary>
	    <p>Бурное развитие внутреннего туризма привело Томаса Кука.</p>
	</details>

Атрибута closed не существует. Поэтому, опуская open, вы по умолчанию подразумеваете closed.

Элемент <summary>

Мы бегло взглянули на <summary> в действии, теперь остановимся на нём подробнее. Внутри <summary> могут использоваться строчные элементы, такие как <span> или <strong>. Для чего это может быть нужно? Например, для дополнительного оформления или, как предлагает спецификация, использования <label> для элемента формы. По крайней мере, было бы удобно, если бы подобная конструкция работала корректно:

	<details>
	    <summary><label for="name">Имя:</label></summary>
	    <input type="text" id="name" name="name" />
	</details>

Теоретически, нажатие на <summary> должно раскрывать содержимое элемента <details>. Но в этом примере содержимое не будет развернуто, потому что вы, фактически, взаимодействуете с <label>, который переводит фокус на соответствующий <input> — даже если он скрыт с помощью <details>.

Честно говоря, этот момент еще требует прояснения. А что по вашему мнению должно происходить? Возможно, у разработчиков браузеров, читающих эту статью, есть какие-то идеи? :)

Вложенность <details>

Вы можете помещать <details> друг в друга, если хотите, как это сделано в следующем, вполне валидном примере:

	<details>
	    <summary>Вопрос 1</summary>
	    <p>Население превышает широкий кристаллический фундамент.</p>
	    <details>
	        <summary>Приложенные документы</summary>
	        <ul>
	            <li><a href="#">Болгары очень дружелюбны;</a></li>
	            <li>Скумбрия неумеренно перевозит вулканизм;</li>
	            <li>Дождливая погода, куда входят Пик-Дистрикт;</li>
	            <li>Белый саксаул дегустирует живописный утконос;</li>
	        </ul>
	    </details>
	</details>

Примеры использования

Так в каких же случаях вы можете использовать <details>? Первое, что приходит в голову — FAQ. Разработчики часто используют для них «аккордеоны», поэтому <details> замечательно подходит.

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

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

Пример использования <details> из спецификации.

На самом деле, даже глядя сейчас на админку WordPress, я вижу множество возможностей использования <details>. Если у вас есть ещё какие-то идеи и предложения — расскажите о них в комментариях.

Оформление

Как же нам оформить эту штуку? Для элемента, раскрывающего содержимое, в WebKit вы можете использовать псевдо-элемент ::-webkit-details-marker. Небольшой пример:

	details summary::-webkit-details-marker {
	    background: red;
	    color: #fff;
	    font-size: 500%;
	}

Мы также можем позиционировать этот элемент по отношению к родителю. Здесь, например, он прижат к правому краю. В общем-то, и все.

А как же заменить раскрывающий элемент своей иконкой? Используя выборку по атрибуту, вы можете определить, когда <details> раскрыт, а когда закрыт, и применить соответствующее фоновое изображение. Мы делаем примерно то же самое в этом примере, за исключением того, что вместо фонового изображения мы используем псевдо-элемент :after:

	summary::-webkit-details-marker {
	    display: none
	}
	summary:after {
	    background: red;
	    border-radius: 5px;
	    content: "+";
	    color: #fff;
	    float: left;
	    font-size: 1.5em;
	    font-weight: bold;
	    margin: -5px 10px 0 0;
	    padding: 0;
	    text-align: center;
	    width: 20px;
	}
	details[open] summary:after {
	    content: "-";
	}

В этом примере символы + и - используются в качестве раскрывающей ссылки. В зависимости от дизайна вы можете использовать :before вместо :after, но, в любом случае, оба псевдо-элемента позволяют использование изображения.

Выборка по атрибуту details[open] скрывает в себе некоторые интересные возможности. Как хорошие HTML5-доктора, мы создали доработанный пример, показанный на этом скриншоте:

Оформленный <details> в Chrome.

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

Доступность

К сожалению, на момент написания статьи отсутствует возможность управления <details> с помощью клавиатуры. Стив Фолкнер пишет:

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

Попробуйте сами. Если вы раскроете элемент <details> с помощью мыши, тогда вы сможете использовать клавиатуру для навигации по вложенным элементам, но вы также должны иметь возможность открывать и закрывать <details> с клавиатуры. Что ж, неидеально, но я уверен, что разработчики Chrome скоро с этим разберутся. Правда, ребята?

Обратная совместимость

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

• Обратная совместимость для <details> с помощью jQuery от Матиаса Байненса;
• Еще одна альтернатива <details>, также основанная на jQuery от Мануэля Бье.

Многие из вас захотят использовать Modernizr для определения возможностей браузера, но на данный момент в Modernizr отсутствует проверка поддержки <details>. Матиас, автор приведенного выше решения для обратной совместимости, предлагает использовать этот Modernizr-сниппет.

Зачем вообще это использовать?

Конечно, дарёному коню в зубы не смотрят, но все-таки — почему этот виджет существует в HTML5? Что ж, как и в случае с другими возможностями HTML5, он просто делает нашу жизнь легче. Реализация таких элементов, как календарь, слайдер, прогресс-бар, а теперь ещё и «аккордеон», становится гораздо проще и не требует использования JavaScript. Кто знает, что будет следующим? Нативные табы? Было бы здорово :)

В заключение

В этой статье мы продемонстрировали, как использовать элементы <details> и <summary>. Элемент <details> при помощи <summary> создаёт естественный для браузера интерактивный раскрывающийся виджет.

На текущий момент <details> работает только в Chrome, но, надеюсь, эта ситуация в скором времени изменится. Пока что мы можем использовать в CSS только ::-webkit-details-marker, но есть и множество других CSS-техник. Если у вас есть какой-либо опыт или идеи для использования элемента <details>, расскажите об этом в комментариях.

Перевод оригинальной статьи «The details and summary elements» Тома Лидбеттера (Tom Leadbetter), опубликованной на сайте HTML5Doctor.com.

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

А теперь смотрите, факт: никто сегодня не устанавливает IE6 в качестве основного браузера. Более того, я готов спорить, что никто, будь у него такой выбор, не предпочтёт IE6 любому другому браузеру. Но проблема не в этом. Теперь нам ясно: никто, блин, специально не выбирает IE6 и уж точно не использует этот браузер, чтобы просто вас взбесить!

Кстати, когда IE6 наконец-то помрёт, кто займётся поиском и заменой IE6 на IE7 во всех записях, а потом IE7 на IE8 и так далее?

Вполне очевидно, что когда компания АБВ во времена XP и IE6 приобретала оборудование для своих сотрудников, это стоило ей чёртову кучу денег. Компании не любят тратить деньги, когда им кажется, что это совсем не нужно. Поэтому очередное обновление всех этих ПК не входит в их приоритеты. Не забывайте, что обновление тянет за собой поддержку, обслуживание, простой и так далее — всё, что стоит ещё одну чёртову кучу денег.

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

Их работа. За которую им платят. Если вы не хотите поддерживать IE6 — не поддерживайте. Никто не выкручивает вам руки, заставляя фрилансить над подобными проектами. Если вы настолько против IE6 и имеете постоянную работу — я надеюсь, что вы упомянули это на собеседовании, но если нет — и вы действительно ненавидите IE6, то вы можете уволиться и найти другую работу, правильно?

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

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

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

Разработка для сети подразумевает, что вы знаете как работают браузеры. Суть такой работы заключается в том, чтобы сайты работали везде. Знание всех «подводных граблей» браузеров — это то, что отличает Ваньку Середнячка от господина Николая Великолепного. Если вы не хотите учить трюки IE6 (или IE7, или IE8, или IE9) — не надо. Вашу работу заберёт кто-нибудь другой.

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

Перевод оригинальной заметки «What do you mean, you don’t like IE6? Really?» Реми Шарпа (Remy Sharp), опубликованной в блоге «rem @ > 140 characters».

Не используйте <section> как обёртку для оформления

Одна из самых распространённых проблем, которую я часто вижу в разметке сайтов — это произвольная замена элементов <div> структурными элементами из HTML5, особенно замена оформительской обёртки на <section>. В XHTML или HTML4 я бы увидел что-нибудь такое:

	<!-- Не копируйте этот код! Он неправильный! -->
	<div id="wrapper">
	    <div id="header">  
	        <h1>Моя супер-пупер страница</h1>
	        <!-- Содержимое шапки -->
	    </div>
	    <div id="main">
	        <!-- Содержимое страницы -->
	    </div>
	    <div id="secondary">
	        <!-- Вторичное содержимое -->
	    </div>
	    <div id="footer">
	        <!-- Содержимое подвала -->
	    </div>
	</div>

Вместо этого я вижу следующее:

	<!-- Не копируйте этот код! Он неправильный! -->
	<section id="wrapper">
	    <header>  
	        <h1>Моя супер-пупер страница</h1>
	        <!-- Содержимое шапки -->
	    </header>
	    <div id="main">
	        <!-- Содержимое страницы -->
	    </div>
	    <section id="secondary">
	        <!-- Вторичное содержимое -->
	    </section>
	    <footer>
	        <!-- Содержимое подвала -->
	    </footer>
	</section>

Честно говоря, это неправильно: <section> — это не обёртка. Элемент <section> определяет смысловую секцию содержимого для создания структуры документа. Он должен содержать заголовок. Если вы ищете элемент для того чтобы обернуть в него всю страницу (в стиле HTML или XHTML), подумайте, не применить ли стили непосредственно к элементу <body>, как описано у Крока Кеймена. Если же вам всё ещё нужна дополнительная обёртка, используйте <div>. Раз уж Доктор Майк объясняет, что <div> не мёртв, а вам не удаётся найти ничего более удачного, пожалуй, этот элемент будет самым подходящим для создания оформительской обёртки.

Таким образом, корректной разметкой для упомянутого выше примера с использованием HTML5 и пары ролей ARIA будет следующий код. Обратите внимание, что вам, в зависимости от дизайна, всё ещё могут понадобится экстра-элементы <div>.

	<body>
	    <header>  
	        <h1>Моя супер-пупер страница</h1>
	        <!-- Содержимое шапки -->
	    </header>
	    <div role="main">
	        <!-- Содержимое страницы -->
	    </div>
	    <aside role="complementary">
	        <!-- Вторичное содержимое -->
	    </aside>
	    <footer>
	        <!-- Содержимое подвала -->
	    </footer>
	</body>

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

Используйте <header> и <hgroup> осознанно

Нет смысла писать разметку, если этого можно не делать, так ведь? К сожалению, я часто вижу элементы <header> и <hgroup> там, где они совсем не нужны. Вы можете узнать все подробности в наших статьях, посвящённых элементу <header> и элементу <hgroup>, но я коротко резюмирую:

• Элемент <header> представляет собой группу вводного содержимого или навигационных средств и обычно содержит структурный заголовок.
• Элемент <hgroup> группирует набор элементов от <h1> до <h6>, представляя собой структурный заголовок в случае, когда заглавие имеет несколько уровней, вроде подзаголовков, альтернативных названий или слоганов.

Злоупотребление <header>

Думаю, что вы в курсе, что <header> можно использовать в документе несколько раз. Но эта возможность привела к следующим ошибкам:

	<!-- Не копируйте этот код! Он неправильный! -->
	<article>
	    <header>  
	        <h1>Мой лучший пост</h1>
	    </header>
	    <!-- Содержимое записи -->
	</article>

Если ваш <header> содержит единственный заголовок, избавьтесь от ненужного <header>. Элемент <article> в любом случае гарантирует, что заголовок войдёт в смысловую структуру документа. И поскольку <header> не содержит нескольких элементов, как указано в его описании, зачем вам код, который, в общем-то, не нужен? Будьте проще:

	<article>
	    <h1>Мой лучший пост</h1>
	    <!-- Содержимое записи -->
	</article>

Неправильное использование <hgroup>

Раз уж зашла речь о заголовках — я часто вижу неправильное использование <hgroup>. Не следует использовать <hgroup> в сочетании с <header> в случае, когда:

• дочерний заголовок всего один или
• элемента <hgroup> будет достаточно и без <header>.

Первая проблема выглядит так:

	<!-- Не копируйте этот код! Он неправильный! -->
	<header>
	    <hgroup>  
	        <h1>Мой лучший пост</h1>
	    </hgroup>
	    <p>Ричард Кларк</p>
	</header>

В этом случае стоит избавиться от <hgroup> и оставить только заголовок:

	<header>
	    <h1>Мой лучший пост</h1>
	    <p>Ричард Кларк</p>
	</header>

Следующая проблема состоит в очередном использовании элементов там, где они необязательны:

	<!-- Не копируйте этот код! Он неправильный! -->
	<header>
	    <hgroup>  
	        <h1>Моя компания</h1>
	        <h2>Основана в 1893 году</h2>
	    </hgroup>
	</header>

Когда <hgroup> — это единственный дочерний элемент <header>, то какой смысл в этом <header>? Если в нём нет дополнительных элементов, соседствующих с <hgroup>, смело избавляйтесь от <header>.

	<hgroup>  
	    <h1>Моя компания</h1>
	    <h2>Основана в 1893 году</h2>
	</hgroup>

Больше примеров использования <hgroup> вы можете найти в отдельной, более подробной статье.

Не оборачивайте все списки ссылок в <nav>

На момент написания статьи существует более 30-ти новых элементов и неудивительно, что у нас разбегаются глаза, когда дело доходит до создания осмысленной структурной разметки. Поэтому не стоит злоупортреблять всеми доступными сейчас суперсемантическими элементами. Что, к сожалению, часто происходит с элементом <nav>. Спецификация определяет роль <nav> следующим образом:

Элемент <nav> представляет собой часть страницы, которая ссылается на другие страницы или части текущей, то есть раздел с навигационными ссылками.

Замечание: не все группы ссылок на странице должны быть обёрнуты в элемент <nav> — этот элемент, главным образом, предназначен для группировки главных навигационных блоков. В частности, в подвалах часто содержатся короткие списки ссылок на различные части сайта, вроде правил использования сервиса, домашней страницы и копирайтов. Элемента <footer> вполне достаточно для группировки такого рода ссылок; и несмотря на то, что элемент <nav> может быть использован в таких случаях, обычно в этом нет необходимости.

Спецификация WHATWG HTML

Ключевая фраза — «главных навигационных блоков». Мы можем дискутировать весь день о значении слова «главный», но для меня это значит:

• Самая главная навигация;
• Поиск по сайту;
• Вторичная навигация (что спорно);
• Внутренняя навигация (по длинной статье, например).

И хотя здесь не может быть «правильного» или «неправильного» использования, поверхностный опрос вкупе с моей собственной интерпретацией говорят, что следующие случаи не подходят для использования <nav>:

• Постраничная навигация;
• Социальные ссылки, за исключением тех случаев, когда такие ссылки являются основной навигацией, к примеру, на сайтах About Me и Flavours;
• Тэги к записи в блоге;
• Категории записи;
• Навигация третьего уровня;
• Подвалы, набитые ссылками.

Если вы не уверены, стоит ли оборачивать список ссылок в <nav>, просто спросите у себя: «главная ли это навигация?» Чтобы было легче ответить на этот вопрос, обратитесь к следующим правилам:

• «Не используйте <nav>, если кажется, что в этом случае может подойти и <section> с заголовком <hx>», — Ян Хиксон, IRC.
• Добавите ли вы этот блок в список ссылок «перейти» для улучшения доступности?

Если ответ на оба эти вопроса «нет», то, скорее всего, это не <nav>.

Общие ошибки с элементом <figure>

Ах, <figure>. Правильным использованием этого элемента вместе с подельником <figcaption> не так-то просто овладеть. Рассмотрим некоторые общие проблемы, которые я вижу при использовании <figure>.

Не каждая картинка это <figure>

Ранее я советовал вам не писать лишний код там, где этого не требуется. Та же ошибка и здесь. Я видел сайты, где каждая картинка была обёрнута в <figure>. Нет никакой необходимости в добавлении экстра-разметки вокруг картинок только ради самого процесса. Вы просто делаете лишнюю работу и нисколько не улучшаете описание содержимого страницы.

Спецификация обозначает <figure> как «содержимое в потоке, с необязательным заглавием, самодостаточное, обычно упоминаемое в качестве смысловой единицы в основном тексте». Как раз в этом состоит вся красота элемента <figure>, который может быть перемещён из основного содержимого, скажем, в колонку, что никак не повлияет на основной поток документа.

Если это исключительно оформительская картинка, никаким образом не упомянутая в основном документе, то это точно не <figure>. Есть и другие варианты использования, но просто спросите себя: «Нужна ли эта картинка для лучшего понимания контекста?» Если нет, то это вероятно не <figure>, а, возможно, <aside>. Если да, спросите себя: «Можно ли переместить эту картинку в примечания к тексту?» Если ответ на оба вопроса «да», то это, вероятнее всего, <figure>.

Ваш логотип — это не <figure>

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

	<!-- Не копируйте этот код! Он неправильный! -->
	<header>
	    <h1>
	        <figure>
	            <img src="logo.png" alt="Моя компания">
	        </figure>
	        Название компании
	    </h1>
	</header>
	 
	<!-- Не копируйте этот код! Он неправильный! -->
	<header>  
	    <figure>
	        <img src="logo.png" alt="Моя компания">
	    </figure>
	</header>

Добавить здесь нечего: это совсем неправильно. Мы можем спорить до посинения насчёт того, должно ли лого находиться внутри <h1>, но мы здесь не за этим. Настоящая проблема — в неправильном употреблении <figure>. Этот элемент должен использоваться, только если он упоминается в документе или контексте общего структурного элемента. Будет честным признать, что ваш логотип вряд ли будет упомянут подобным образом. Просто не делайте так. Всё, что вам нужно, это:

	<header>
	    <h1>Название компании</h1>
	    <!-- и всё остальное здесь -->
	</header>

Элемент <figure> — это не только картинки

Другое распространённое заблуждение насчёт <figure> — что он может быть использован только для картинок. Это не так. Элемент <figure> может быть видео, аудио, графиком (на SVG, к примеру), цитатой, таблицей, блоком кода, фрагментом текста или любой комбинацией этих и многих других элементов. Не ограничивайте использование <figure> только картинками. Наша работа, как энтузиастов от веб-стандартов, заключается в том, чтобы максимально точно описывать содержимое при помощи разметки.

Некоторое время назад я писал про <figure> детальнее. Рекомендую почитать, если вам интересно узнать подробности или просто освежить знания.

Не используйте ненужные атрибуты type

Эта проблема, пожалуй, является самой распространённой среди заявок в Галерею HTML5. И хотя это, по сути, не ошибка, мне кажется, что правильнее будет её избегать.

Дело в том, что в HTML5 не нужно добавлять атрибут type для элементов <script> и <style>. Если эти элементы автоматически добавляются вашей CMS, то избавиться от них может быть непросто, но если вы пишете код руками или полностью контролируете шаблоны, то нет никакого смысла писать избыточные атрибуты. Поскольку все браузеры ожидают, что скриптами будет JavaScript, а стилями CSS, вам это совсем не нужно:

	<!-- Не копируйте этот код! Он неправильный! -->
	<link type="text/css" rel="stylesheet" href="styles.css">
	<script type="text/javascript" src="scripts"></script>

Вместо этого просто напишите:

	<link rel="stylesheet" href="styles.css">
	<script src="scripts"></script>

Кроме того, вы можете уменьшить объём кода, который пишете для задания кодировки документа и других вещей. Глава про семантику в «Погружении в HTML5» Марка Пилгрима объясняет всё.

Неправильное использование атрибутов форм

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

Одиночные атрибуты

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

	autofocus
	autocomplete
	required

Надо признаться, я нечасто встречал подобное, но если в качестве примера взять атрибут required, то попадалось следующее:

	<!-- Не копируйте этот код! Он неправильный! -->
	<input type="email" name="email" required="true">
	<!-- Ещё один плохой пример -->
	<input type="email" name="email" required="1">

В конечном счёте это никому не вредит. HTML-парсер видит атрибут required в разметке, поэтому требуемая функциональность будет включена. Но что, если поставить код вверх ногами и написать required="false"?

	<!-- Не копируйте этот код! Он неправильный! -->
	<input type="email" name="email" required="false">

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

Существует три правильных способа задания одиночных атрибутов, второй и третий из которых нужны только если вы пишете XHTML:

	required
	required=""
	required="required"

Если применить эту запись к нашему примеру (в HTML), получится следующее:

	<input type="email" name="email" required>

Резюме

Было бы просто невозможным перечислить здесь все странные приёмы и образцы разметки, с которыми мне довелось столкнуться, но эти — одни из самых часто встречавшихся. А какие ещё ошибки разметки бросались вам в глаза? Расскажите в комментариях.

Перевод оригинальной статьи «Avoiding common HTML5 mistakes» Ричарда Кларка (Richard Clark), опубликованной на сайте HTML5Doctor.com.

• <small> — использовался раньше для того, чтобы просто сделать текст помельче, теперь же он предназначен для пометок и небольших надписей (W3C:Markup, WHATWG);
• <hr> — использовался раньше для создания горизонтальных линеек, теперь предназначен для смысловой разбивки на уровне текстовых блоков (W3C:Markup, WHATWG).

Элемент <small>

Элемент <small> представляет собой так называемые «надписи мелким шрифтом», вроде тех, что используются для предостережений и оговорок в юридических документах.

Спецификация W3C

Теперь <small> применяется для пометок и является более локальным аналогом элемента <aside> — для второстепенной информации на странице. Типичным примером будет следующая за основным содержимым юридическая болтовня, вроде заявлений об авторском праве в подвале, отказе от ответственности, или же информации о лицензии. Он также может быть использован для указания авторства. Не используйте его для содержимого на блочном уровне (параграфы, списки и т.д.), иначе это будет воспринято как основное содержимое.

	<p>
	    Я использую
	    <span class="museo">Museo Slab</span>,
	    <small class="font-license">
	        шрифт Жоса Буйвенга (exljbris)
	        <a href="http://www.exljbris.nl/">www.exljbris.nl</a>
	    </small>
	</p>

Использование <small class="font-license"> для того, чтобы выполнить требования лицензионного соглашения

	<small>
	    <a href="http://creativecommons.org/licenses/by-sa/3.0/"
	        rel="license">
	        Creative Commons Attribution Share-alike license
	    </a>
	</small>

Использование <small> вокруг ссылки на Creative Commons license с rel="license"

Текст внутри <small> необязательно должен быть меньше, чем окружающий — если же вам нужен именно мелкий текст, то для этого лучше подойдет CSS. Используйте <small> только на строчном уровне. В конце концов, <small> не влияет на семантику <em> или <strong>.

Элемент <hr>

<hr> служит для смысловой разбивки на уровне блоков текста

Спецификация W3C

Пообщавшись с Яном Хиксоном (редактором HTML5) я понял, что до сих пор неправильно понимал модель поведения содержимого. Я узнал, что <hr> на самом деле означает конец одной секции и начало другой — что семантически равносильно </section><section>. Но поскольку элементы вроде <section> и так указывают на это, получается, что <hr> больше подходит для смысловой разбивки, вроде смыслового разделения внутри блока текста или отделения одной сцены в романе от другой. В любом случае, вы можете использовать этот элемент везде, где вы используете элемент <p>. Из-за унылого вида в браузерах по умолчанию, <hr> не слишком распространён сегодня, однако это не мешает оформить его при помощи CSS в виде красивого вензеля.

	hr {
	    margin:3em 0;
	    height:24px;
	    border:0;
	    background:url(flourish.png) 50% 50% no-repeat;
	    }

Оформите <hr> красиво: уберите рамку, поля и добавьте фоновую картинку.

IE7 и младше оправдывают свою дурную репутацию, добавляя рамку вокруг изображения, несмотря на наши усилия, но и это можно исправить. Или же вы можете просто скрыть <hr> в стилях для IE7 и младше. Если переход между частями содержимого очевиден или разделение чисто визуальное, а не смысловое, то вместо <hr> лучше нарисовать рамку или фоновую картинку на другом элементе.

На Cork’d используеся декоративная фоновая картинка для заголовков. Но несмотря на обилие линеек, это совсем неподходящий случай для использования <hr>.

В заключение

В момент выхода HTML4, презентационные элементы <basefont>, <font>, <s>, <strike> и <u> уже были помечены как нежелательные для использования, в пользу применения CSS. HTML5 завершил этот процесс, избавившись от элементов <big> и <tt>.

Остальные презентационные элементы из HTML4 — долго игнорируемые <small> и <hr> (наряду с <i> и <b>) — были пересмотрены в HTML5 с учетом их полезных, медиа-независимых семантических свойств, которые имеют отношение к их типичному использованию. Будете ли вы использовать их? Выскажитесь в комментариях!

Перевод оригинальной статьи «The small & hr elements» Оли Стадхольма (Oli Studholme), опубликованной на сайте HTML5Doctor.com.

К примеру многие знают, что цвет в шестнадцатеричной нотации вида #RRGGBB можно писать сокращённо как #RGB, если каждый старший разряд совпадает с младшим, или что нуль можно писать без единиц измерения, таких как «px» или «em», так как нуль — в любой системе измерения нуль.

Что считает браузер

Также широко известно, что можно отцентрировать блок с шириной меньше родительского элемента при помощи margin:0 auto. Однако мало кто задумывается, что почти во всех случаях дело касается непозиционированных элементов, и в этом случае значение margin-top:auto или margin-bottom:auto устанавливается равным нулю, а значит данное правило можно сократить до простого margin:auto.

Правила margin-left:auto и margin-right:auto при ширине блока меньше ширины контейнера равномерно распределяют оставшееся место. Так, задав только margin-left:auto, можно выровнять элемент по правому краю.

В обычном потоке элементы идут сверху вниз, поэтому margin-top:auto устанавливается нулевым. Однако для абсолютно спозиционированных элементов действует то же распределение свободного места, и аналогичным образом можно сделать центрирование по вертикали при заданных высоте и top с bottom (не работает в IE7).

Сокращения и значения по умолчанию

Не менее широко распространено использование спрайтов, например: background:url(icons.png) 0 0 no-repeat. Однако, background-position:0 0 является значением по умолчанию, поэтому 0 0 в таком случае можно опустить.

Но если в background-position задана хоть одна координата: будь то top, left или 100%, то вторая принимает значение 50%. Это может быть полезно для значков, выровненных посередине строки по вертикали — достаточно указать лишь положение слева или справа.

Не все знают, что опущенные в сокращённой записи правила принимают своё значение по умолчанию. Поэтому уточняющие правила надо писать после или делать сильнее общей сокращённой надписи, как background-position уточняет положение каждого спрайта после background в предыдущем примере.

При подобном написании:

	h1 {
	    font:2em/1 Arial,sans-serif;
	}

задаётся не только шрифт, его размер и интерлиньяж, но и сразу сбрасывается полужирное написание (font-weight:normal), а также другие свойства, такие как font-style (курсив) и font-variant (капитель). Некоторые авторы совершенно зря дописывают в font значение normal. Непонятно даже к какому правилу из перечисленных трёх оно могло бы относиться — порядок следования в сокращённых свойствах неважен, и неучитывание порядка могло приводить к ошибкам лишь в устаревших браузерах.

Другими недопонятыми, но тоже полезными сокращёнными записями являются отдельные правила рамок border-width, border-style и border-color. Например, благодаря им можно задать верхнюю и нижнюю одинаковые рамки не дублированием кода в border-top и в border-bottom, а подобным образом:

	border:solid gray;
	border-width:3px 0;

Кроме меньшего размера кода, такая запись полезна тем, что каждое значение написано только один раз, и поменять, скажем, solid на double не составляет труда.

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

Есть возможность, что border-radius может быть включен в сокращённую запись border (предлагался вариант с косой чертой «/»), поэтому записывайте на всякий случай border-radius после border.

Переусложенение

Часто, чтобы избавиться от рамки на картинке внутри ссылки, пишут:

	a img {
	    border:0;
	}

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

	img {
	    border:0;
	}

Эффект будет тот же самый. Уточнение, что рамка появляется на ссылках a в данном случае совершенно излишне.

Из тех же соображений производительности, как правило, незачем писать имя тэга вместе с классом и уж тем более с идентификатором, который сам по себе уникален. В данном правиле могут быть только два исключения: уточнение для конкретного тэга (возможно в этом случае у вас очень общий класс), и обход недостатка IE7, где эффекты при наведении :hover тормозят, если в селекторе не указан тэг (то есть надо писать a.class:hover { color:#FC0; }).

Наследование

Ещё одна недооценённая многими возможность CSS: наследование стилей. Например, может не устраивать, что по умолчанию содержимое ячеек таблиц центрируется по вертикали, при этом используются следующие правила:

	th {
	    vertical-align:bottom;
	}
	td {
	    vertical-align:top;
	}

Вроде бы всё здорово, но, сделав так, вы лишаетесь простого способа переопределить выравнивание для целого ряда:

	tr.images {
	    vertical-align:middle;
	}

Этого можно избежать, воспользовавшись тем, что ячейки таблицы th и td наследуют правила от рядов tr, а те в свою очередь от блоков thead, tfoot и tbody.

	thead {
	    vertical-align:bottom;
	}
	tbody,
	tfoot {
	    vertical-align:top;
	}

Стоит отметить, что все браузеры, кроме IE8, наследуют еще и значение text-align для th, а сам IE8 понимет ключевое слово inherit, что также позволяет наследовать значение text-align.

Заключение

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

Для начала определимся в терминологии. В CSS-коде у нас есть: блок правил — селектор и список правил для него; каждое правило состоит из свойства и его значения.

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

	.example { position:absolute; top:10px; display:block; width:10px; height:10px; background:url(icon.png) no-repeat }

Многострочное форматирование, каждая пара свойство:значение на новой строке:

	.example {
	    position:absolute;
	    top:10px;
	    display:block;
	    width:10px;
	    height:10px;
	    background:url(icon.png) no-repeat;
	    }

Однострочный способ хорош в «наборах», «батареях» селекторов с одинаковыми свойствами. Например, там, где одно свойство принимает разные значения:

	.tag-cloud .xs    { font-size:0.5em }
	.tag-cloud .s     { font-size:0.75em }
	.tag-cloud .m     { font-size:1em }
	.tag-cloud .l     { font-size:1.25em }
	.tag-cloud .xl    { font-size:1.5em }
	.tag-cloud .xxl   { font-size:1.75em }

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

Анализ

Работа с кодом — это операции написания, поиска и редактирования текста. Чтобы работать результативно, нужно преследовать две цели:

Цель №1: минимизация шанса на ошибку

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

Цель №2: скорость восприятия свойств

Основной труд при написании CSS файла — это объявление значений определенных свойств. Значит, нужно иметь набор этих свойств наглядно и под рукой, в рамках одного селектора.

Разве вам нужно следить за огромным количеством строк одновременно? Посмотрите, например, как думает программист, пишущий новую функцию. Его внимание сосредоточено только на этой функции. Так и у верстальщика — работа идет одновременно только с одним селектором. Столбик — самая наглядная запись. Он является потомком примитивного списка в столбик. Вы же не будете отрицать, что вытянутые в строку элементы списка теряют в доступности?

Например, довольно трудно найти отдельный элемент этого списка:

	Я полюбил { Машеньку:болтушку; Юшечку:тихоню; Лизоньку:умницу; Алиночку:скромницу }

Гораздо проще найти нужный нам пункт в таком виде:

	Я полюбил {
	    Машеньку:болтушку;
	    Юшечку:тихоню;
	    Лизоньку:умницу;
	    Алиночку:скромницу
	    }

Не нужно думать, что HTML-верстка это нечто обособленное в плане написания кода. Обратите внимание на практики, которые используют программисты, пишущие на JavaScript, PHP или Perl. Пара свойство:значение в CSS — это объявление той же переменной, только с ограниченным вариантом значений.

Пример JavaScript-кода:

	function example() {
	    var position = 'absolute', display = 'block', width = 10, height = 10, background = 'icon.png';
	    …
	}

То же самое, но в традиционном для JavaScript стиле форматирования:

	function example() {
	    var position = 'absolute',
	        display = 'block',
	        width = 10,
	        height = 10,
	        background = 'icon.png';
	    …
	}

Теперь давайте вернёмся и еще раз перечитаем как сформулирована цель №2: ключевое слово «свойства». Нам не так часто приходится править селектор или расположение блоков с селекторами, но очень часто приходится править набор правил, иметь ввиду значение свойств, следить, какие уже объявлены, а каких еще нет. Именно поэтому важно сконцентрировать свое внимание на наборе правил.

Автоматизация

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

Среди автоматических способов решения проблем первым стоит упомянуть построчную валидацию CSS-свойств в рамках селектора. Пусть машина помогает вам находить опечатки и проблемные фрагменты кода:

При многострочном форматировании сложнее пропустить:

• переопределение одного правила другим и уже объявленное правило;
• пропущенную ; в последовательности правил;
• незаметные опечатки, вроде height и heigth;
• хаки.

Визуализация цветов

У каждой строки с использованием цветового кода мой редактор визуализирует цвет. Это нагляднее. Привлекает внимание быстрее. Еще один способ быстро найти нужное.

Порядок свойств, селекторов, решений

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

Я рекомендую разбить ваш CSS на три части. Это может быть как в прямом смысле разделение по файлам, так и просто мысленное принятие этого правила. Первая часть — это сброс умолчаний, так называемый reset.css, вторая — правила для HTML-тегов, третья — объявления классов и уникальных идентификаторов. Любой из этих частей может и не быть, но так можно организовать порядок на верхнем уровне. В каждой из этих частей всё тоже можно организовать: теги сгруппировать по функциональному признаку, классы и идентификаторы по решениям.

После того, как сделано всё вышесказанное, возникает вопрос: как организовать свойства в рамках одного селектора — по алфавиту, по длине записи, по частоте использования? Эти методы не годятся потому, что организация, навязываемая ими, не отвечает нашим целям. Вот, например, всё отсортировано по алфавиту, и чтобы увидеть какой z-index у абсолютно позиционированного блока, нужно выискивать его вдалеке от position:absolute, а свойство left совершенно неочевидно будет соседствовать с letter-spacing.

Наиболее правильный метод — это функциональная группировка. Например: позиционирование, поведение блока, размеры, цвета и т.д. Один из наиболее продуманных вариантов сортировки есть в документации к проекту Zen Сoding.

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

Дополнительное окно

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

Сравнение содержимого построчно

Вы можете писать однострочный CSS, но вполне вероятно что вы вырастете до работы над большими проектами с множеством файлов и большим объемом CSS. Вам придётся работать с системой контроля версий, построением проекта и другими разработчиками в вашей команде. Обратите внимание на то, что разница между двумя файлами вычисляется именно построчно, и при однострочной записи вам будет труднее выявить различия, так как строка будет различаться сразу несколькими свойствами:

Доступ по селектору через поиск

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

Доступ к свойству конкретного селектора по номеру строки

Номер строки можно найти так: проинспектировать нужный блок в верстке с помощью Firebug, Web Inspector или Dragonfly, затем найти нужный селектор, который срабатывает для данного блока и подсмотреть номер строки и имя файла. Далее дело техники и знания горячих клавиш вашего любимого редактора. Объем CSS-кода и его растянутость (излишняя, как считают некоторые) не имеет никакого значения в этом случае.

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

При построчной записи удобнее комментировать конкретное свойство. Например напомнить, что оно переопределено в файле ie6.css. Или указать, что эта ширина может меняться в зависимости от наличия другого класса.

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

При должной сноровке и знании горячих клавиш вашего любимого редактора закомментировать одно свойство на одной строке — легко. Комментарий /* … */ автоматически обхватит свойство в многострочной записи. В однострочной записи вам недоступна такая роскошь. А я комментирую, ломая имя свойства иксиком или другим символом — детский сад, и к тому же небезопасно для обработки браузером дальнейшего кода. Не стоит испытывать на прочность CSS-парсеры.

А у меня CSS меньше и быстрее

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

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

В итоге

Рекомендую пересилить себя и в целях повышения продуктивности, как личной, так и вашего проекта в целом, задуматься: почему вы пишете именно так? Может дело в простой привычке? Если вы преследуете цель №1 и цель №2, то настоятельно рекомендую переходить на многострочный стиль.

Дополнительное чтение

• CSS-менеджмент. Три года спустя, доклад Вадима Макеева;
• Eclipse: знакомство с Ant, статья Сергея Чикуёнка;
• CSScomb.ru, инструменты для сортировки CSS-свойств.

В этой статье я постарался рассмотреть все самые распространенные вопросы, сомнения и критику по поводу необходимости создания и внедрения новых механизмов раскладки. Cтатья дополняет и продолжает содержание моего выступления «CSS3: будущее механизмов раскладки». Если вы его не смотрели, то рекомендую ознакомиться.

Итак, у нас есть три черновика модулей CSS3: Grid Positioning Module, Flexible Box Layout, Template Layout. Каждый ценен своей уникальной идеей. Эти идеи специально спроектированы для решения определенного рода задач по раскладкам. Задач, которые в настоящее время решают не предназначенными для этого методами. Отсюда сложности в разработке и поддержке, ограничения и даже побочные эффекты этих методов.

Долететь до Луны, используя катапульту

Эра CSS-вёрстки, как и эра бурного развития клиентских технологий, длится не так уж и долго. С большой натяжкой — каких-то полтора десятка лет. Сначала все сайты не имели никаких раскладок. Даже графика была редкостью. Затем в веб стали приходить бизнес, индустрия развлечений, СМИ… Требования к представлению информации несоизмеримо выросли.

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

То, что нельзя прочитать в спецификации

Теперь давайте рассмотрим несколько вопросов, возникающих при размышлении о раскладках.

Чем не устраивает float?

Свойство float способно наделять блоки плавающим поведением. Можно поместить блок слева или справа в контексте других блоков. Недостаточная гибкость float заключается в невозможности поместить блок в контексте других блоков, не прижимая его к краям этого контекста. Такого поведения можно добиться, используя модуль Grid.

Почему бы просто не реализовать display:table во всех браузерах и не забыть про эти многочисленные модули?

Я полностью поддерживаю стремление реализовать display:table во всех браузерах. Но это вовсе не означает, что display:table сможет дать нам гибкий и перспективный механизм создания раскладок. Как можно поменять местами две колонки, не меняя HTML-разметки? Или как, например, возможно поместить блок, который будет одновременно находиться в области этих двух колонок, и при этом их содержимое будет его обтекать? Свойство display:table (как и свойства position и float) проектировалось совсем не для создания раскладок.

Кто круче: Grid, Flexbox, Template?

Очень хороший вопрос: какой из этих трёх модулей лучше, и кто в итоге должен выиграть? На самом деле, сила этих модулей именно в комбинировании возможностей и в совместном их использовании. Эти модули не стоит воспринимать как конкурентов друг другу. Наоборот, в основе каждого лежит идея позволяющая реализовать уникальные вещи. Так, Grid предназначен для создания сетки и привязки к этой сетке; Flexbox реализует особый механизм поведения блоков; Template создает набор слотов и позволяет, управляя ими, строить раскладки.

Что за разговор, это же всё очень сырое и потому неинтересное!

Это действительно интересный момент. Сырое, согласен. Но почему никого не смущают и, напротив, очень даже интересуют сырые реализации box-shadow и border-radius, а также остальных модных оформительских CSS-свойств. Лично меня очень расстраивает эта возня около вещей, продиктованных модой. Сегодня уголки квадратные, завтра круглые… а послезавтра?

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

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

Mozilla сказала своё слово, разработав и внедрив Flexbox. Чей ход теперь?

Справедливости ради нужно сказать, что Flexbox работает не только в Firefox, но и в Safari и в Chrome. А это уже три браузера из большой пятерки. Мой прогноз: в ближайший год IE или Opera введут поддержку этого модуля. Причем я больше склоняюсь в сторону IE. Предпосылки к этому есть — активное обсуждение в рассылке www-style, где Рабочая группа CSS (CSS Working Group) и все желающие обсуждают технические вопросы.

Давайте сделаем тег <layout>?

Это совсем провальное намерение. Идеология открытого веба, к которому мы все так стремимся, гласит: отделяй данные от их представления. Таким образом, внедрять экстра-разметку или какие-либо заведомо стилизованные теги — тупиковый путь.

И главное: <layout> — это путь в каменный век табличной вёрстки. Подобные методы не оправдали себя в создании гибких раскладок. Вот простой пример: нужно изменять внешний вид страницы и саму раскладку в зависимости от размеров окна браузера. С HTML-разметкой это невозможно. А сейчас для этого существует CSS-модуль Media Queries.

Какие преимущества мы получаем?

Создавать раскладку при помощи Grid, Flexbox и Template гораздо проще. Следовательно, не нужно оплачивать труд CSS-гуру или самому быть им. Это совсем не означает, что высококвалифицированному специалисту будет нечего делать. Наоборот, он найдет себе применение в решении более интересных задач вёрстки.

Создавать раскладки можно гораздо быстрее, а значит — можно сократить сроки вёрстки.

Раскладка на Grid, Flexbox и Template более функциональная и гибкая. Таким образом, внесение изменений будет обходиться дешевле, проще и быстрее.

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

Главный вопрос

Сейчас не нужно выдумывать ничего нового. Нужно сосредоточить свое внимание на этих спецификациях. Осознать, что уже проделана огромная работа по придумыванию и обсуждению этих идей. Также важно, что именно Рабочая группа CSS занимается этими вопросами. Эти идеи родились в их умах. В умах людей, которые сегодня имеют непосредственное отношение к разработке браузеров. На этом уровне вопросы не решаются мгновенно, но на динамику и приоритет новых механизмов раскладок можно повлиять. К профессиональному сообществу веб-разработчиков производители браузеров, их специалисты по связям с разработчиками, технические специалисты и руководство прислушиваются всегда. Так может, спросим все вместе: «Когда же?»

И конечно же, по поводу этих префиксов слышится ворчание. Звучат призывы совсем отказаться от них или объединить все специфичные браузерные префиксы в один вида -beta-. Главная причина всего этого шума — никто, на самом деле, не хочет писать одно и то же свойство четыре или пять раз подряд только для того, чтобы, скажем, скруглить уголки.

Даже если это ворчание и можно понять, оно всё равно несправедливо. На самом деле, мы должны благодарить производителей браузеров за использование префиксов и безусловно поощрять их развитие. Более того, я уверен, что префиксы должны стать основой процесса развития стандарта CSS. И я говорю это не от большой любви к повторению правил, а, напротив — от большого желания видеть последовательное развитие CSS. Я верю, что префиксы на самом деле могут ускорить развитие и совершенствование CSS.

Вспоминая ужасы

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

Для наших самых маленьких читателей, пропустивших всё веселье, — история произошла следующая: среди первых браузеров, поддерживающих CSS, Netscape внедрил блочную модель, найденную в CSS-спецификации. Это означало, что свойства width и height соотносились с шириной и высотой границ содержимого блока. А Internet Explorer внедрил интуитивную блочную модель, в которой свойства width и height обозначали размеры по внешней границе блока.

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

Суть проблемы состояла в том, что каждый из браузеров не мог изменить своего поведения до зеркального соответствия другому. Представим на секунду, что команда разработчиков IE решает изменить поддержку CSS для большего соответствия спецификации. Подобный поступок привёл бы к тому, что десятки или даже сотни тысяч сайтов, работавших в IE, не просто где-то там сломаются, а буквально развалятся на части в определённых версиях браузера. И пока всё сообщество веб-стандартистов будет рукоплескать этому поступку, весь остальной мир откажется от браузера по причине полной его бесполезности. И даже если Рабочая группа CSS (CSS Working Group) решит изменить спецификацию для соответствия поведению IE, то Netscape столкнётся ровно с теми же трудностями.

Таким образом и был придуман механизм переключения <DOCTYPE>. Вся эта история со «стандартным» (standards mode) и «хитрым» (quirks mode) режимами выросла как раз из этой ситуации. Механизм переключения <DOCTYPE> решал многие проблемы, но его появление спровоцировали именно сложности с блочной моделью. Вдумайтесь: из-за того, что два браузера вели себя по-разному, сегодняшние браузеры вынуждены поддерживать два основных режима обработки страниц и выбирать нужный на основании SGML-декларации, в которой вообще ничего не сказано про обработку страниц.

Более того, все CSS-хаки первой волны были посвящены именно этой проблеме. Название классического представителя хаков той поры говорит само за себя: «хак для блочной модели» (The Box Model Hack). Фактически, сам хак был основан на ошибке в синтаксической обработке значения свойства voice-family, но почему-то никто ни разу не назвал его «voice-family-хак».

Самое смешное, что это был не единственный случай, в котором непоследовательность внедрения спецификации привела к проблемам. Спустя некоторое время после появления механизма переключения <DOCTYPE>, спасшего CSS, команда разработчиков IE внедрила некоторые CSS-свойства позиционирования. Одним из внедрённых свойств было clip. Наученные горьким опытом шумихи с блочной моделью, инженеры Microsoft с большим вниманием отнеслись к спецификации и сделали всё в точности так, как там было сказано.

Вскоре после публичного релиза браузера, Рабочая группа CSS серьёзно поменяла принцип работы свойства clip. Синтаксис выглядел точно так же, однако приводил совсем к другим результатам.

В очередной раз спецификация вошла в противоречие с публично доступным браузером — или, если хотите, наоборот. Окончательным решением стало возвращение к прежнему поведению и полный отказ от нового. Фактически, это свойство стало бесполезным для элементов с непредсказуемой высотой и шириной — т.е. для всех незамещаемых элементов в нормальном потоке, вроде элементов <div> и <p>. Подробнее о типах элементов (replaced, non-replaced) можно прочитать в документации W3C. Несмотря на то, что были предложены и другие варианты решения, они так и не были реализованы, и свойство clip утратило часть своей полезности.

Представим себе другой исход

Предположим, что вместо внедрения свойства clip разработчики IE внедрили бы свойство -ms-clip. В этом случае было бы не так сложно справиться с последующим изменением поведения в спецификации. Из-за того, что префикс обозначает для свойства статус «в разработке», в дальнейшем производителю браузера будет гораздо проще пересмотреть работу свойства. Таким образом, разработчики IE могли бы поменять поведение свойства -ms-clip, в следующем релизе и объяснить разработчикам, что они обновили экспериментальное свойство для соответствия спецификации.

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

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

Мы конечно можем заявить: «Когда браузер неправ по отношению к спецификации, то он должен изменить реализацию, даже если это сломает вёрстку сайтов». Благодаря предупреждению о рабочем статусе свойства, которое подразумевают префиксы, сделать это становится гораздо проще. Без использования префиксов это крайне сложно или, зачастую, просто невозможно. Microsoft так и не изменила способ расчёта width и height для устаревших сайтов — вместо этого она использовала объявление <DOCTYPE> для включения другого поведения для новых (теоретически, более совместимых со стандартами) сайтов. Это был очень полезный и необходимый трюк, но один из тех, что срабатывают только один раз.

И даже сейчас мы страдаем

И если вы думаете, что все эти глупости стали частью истории, вот вам два примера несовместимости, существующие прямо сейчас:

Браузеры на движках Mozilla и Webkit обрабатывают размытие для свойства box-shadow по-разному, и ни одна из реализаций полностью не соответствует спецификации. И пока я пишу эти строки, длинные и жаркие дебаты кипят в рассылке www-style. По меньшей мере одной, а, возможно, и обеим реализациям размытия тени придётся измениться для достижения совместимости. То же самое справедливо и для реализаций Opera и Microsoft.

Браузеры на движках Mozilla и Webkit поддерживают градиенты, используя категорически разный синтаксис для достижения простых результатов. А теперь представьте ситуацию, в которой производители браузеров внедрили бы градиенты без префиксов. В ней мы имеем три варианта:

1. Выбрать, какой браузер получит градиенты, а какой нет;
2. использовать CSS-хаки или фильтрацию браузеров для выдачи разных стилей разным браузерам;
3. полностью отказаться от использования градиентов.

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

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

Пре-фикс или пост-хак

Но настолько ли хороши префиксы? В конце концов, было же сказано, что префиксы — это всего лишь новые CSS-хаки. Как сказал Аарон Густафсон в недавней статье, это:

-moz-border-radius: 10px 5px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 5px;
-webkit-border-bottom-right-radius: 10px;
-webkit-border-bottom-left-radius: 5px;
 border-radius: 10px 5px;

…слишком напоминает вот эту историю:

padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;

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

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

Поэтому создание единого префикса, вроде -beta- или -w3c- — это, по меньшей мере, полшага назад. Это, конечно, позволит производителям помечать свойства префиксом «в разработке» и делать в дальнейшем необходимые изменения, но, к сожалению, полностью закроет для авторов возможность исключать поддержку или просто отдавать различные значения каждому отдельному браузеру, в случае очередной сомнительной реализации. С точки зрения авторов, единый префикс ничем не лучше, чем полный отказ от них.

Иногда мне кажется, что так же история обстоит и с методами предварительной обработки кода для работы с префиксами — серверными (при помощи LESS) или клиентскими (куча JS-фреймворков). Использование этих инструментов позволяет просто писать правило border-radius и поручать им разворачивание этой строки в список необходимых правил с префиксами. С одной стороны, это уменьшает количество необходимого кода и повышает его чистоту и понятность. С другой стороны, этот подход мало чем отличается от ситуации с единым префиксом или вообще без них — всего одна неудачная реализация, и ваша вёрстка развалится.

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

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

Делаем префиксы действительно важными

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

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

h1 {
    -webkit-text-curl: minor;
    -moz-text-curl: minor;
    -o-text-curl: minor;
    text-curl: minor;
}

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

В этот момент авторы могут решить упростить свои стили до следующих:

h1 {
    -webkit-text-curl: minor;
    text-curl: minor;
}

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

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

h1 {
    -ms-text-curl: minor;
    text-curl: minor;
}

Как только Рабочая группа сочтёт реализацию свойства -ms-text-curl полной, префикс сможет быть отброшен в следующей версии IE. После чего CSS снова может быть уменьшен до единственной беспрефиксной строчки. И снова — количество хаков только уменьшается со временем.

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

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

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

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

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

Заключение

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

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

Перевод оригинальной статьи «Prefix or Posthack» Эрика Мейера (Eric Meyer), опубликованной на сайте A List Apart.