Элемент <figure>

Предполагается, что элемент <figure> будет использоваться в сочетании с элементом <figcaption> для того, чтобы выделять диаграммы, иллюстрации, фотографии и примеры кода (помимо прочего). Вот что говорится о <figure> в спецификации:

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

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

Элемент <figcaption>

Этот элемент стал поводом серьезных споров. Спецификация изначально предлагала приспособить для этих целей элемент <legend>, вместо того, чтобы придумывать новый элемент. Были и другие предложения, включавшие <label>, <caption>, <p> и даже заголовки <h1>—<h6>. Семантика элемента <legend> изменилась, и поэтому мы начали использовать комбинацию <dt> и <dd> внутри <figure> по предложению Джереми. Но большинство этих идей были отклонены из-за отсутствия обратной совместимости для CSS-оформления.

Наши постоянные читатели знают, что недавно был представлен новый элемент <figcaption>. Кто знает, приживется ли он, а пока давайте узнаем, что о нём говорит спецификация:

Элемент <figcaption> представляет собой заголовок или описание для <figure>.

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

Элемент <figcaption> является необязательным и может появляться до или после содержимого внутри <figure>. Только один элемент <figcaption> может быть помещен в <figure>, хотя сам элемент <figure> может содержать несколько дочерних элементов (например, <img> или <code>).

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

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

<figure> для изображения

Изображение в элементе <figure> без подписи:

Вот код для этого:

	<figure>
	    <img src="orang-utan.jpg"
	         alt="Малыш орангутанга свисает с каната">
	</figure>

<figure> с изображением и подписью

Изображение внутри элемента <figure> с поясняющей подписью:

И код, который мы использовали:

	<figure>
	    <img src="macaque.jpg" alt="Макака на дереве">
	    <figcaption>
	        Наглая макака из Борнео.
	        Фото <a href="…">Ричарда Кларка</a>
	    </figcaption>
	</figure>

<figure> с несколькими изображениями

Размещение нескольких изображений внутри одного элемента <figure> с общей подписью:

И сам код:

	<figure>
	    <img src="kookaburra.jpg" alt="Кукабара">
	    <img src="pelican.jpg" alt="Пеликан на пляже">
	    <img src="lorikeet.jpg" alt="Наглый многоцветный лорикет">
	    <figcaption>
	        Слева направо: кукабара, пеликан и многоцветный лорикет.
	        Фотографии <a href="…">Ричарда Кларка</a>
	    </figcaption>
	</figure>

<figure> с блоком кода

Элемент <figure> может быть также использован для примеров кода:

Ниже приведен код для этого:

	<figure>
	    <blockquote>
	        <p><code><small>
	            <a rel="license" href="…">
	                Creative Commons Attribution Share-alike license
	            </a>
	        </small></code></p>
	    </blockquote>
	    <figcaption>
	        Использование элемента <code>&lt;small&gt;</code>
	        вокруг ссылки на лицензию Creative Commons
	        с <code>rel="license"</code>.
	    </figcaption>
	</figure>

Различия между <figure> и <aside>

Мы уже говорили об элементе <aside> в предыдущей статье, но важно отметить разницу между ними. При выборе между <aside> или <figure>, стоит спросить себя, имеет ли содержимое элемента важное значение для понимания содержимого:

• Если содержимое просто имеет отношение и не является существенным, то используйте <aside>.
• Если содержимое является важным, но его положение в потоке общего содержимого не так важно, используется элемент <figure>.

Обратите внимание, что если положение содержимого в тексте тесно связано с предыдущим и последующим содержимым, следует использовать более подходящие элементы — например, <div>, старый добрый <img>, <blockquote>, или даже <canvas>, в зависимости от типа содержимого.

Не останавливайтесь на достигнутом!

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

Однако использование элемента <figure> не всегда целесообразно. Например, графический баннер не стоит размечать в <figure>. Используйте для этого просто <img>.

Вывод

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

Перевод оригинальной статьи «The figure & figcaption elements» Ричарда Кларка (Richard Clark), опубликованной на сайте HTML5Doctor.com.

Перевод выполнила Екатерина Мордвина.

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

В этой статье я постараюсь в понятной форме рассказать про это свойство.

Чего оно не делает

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

Вспоминаются времена, когда мы делали раскладки на основе таблиц:

<td valign="top">
    Что-нибудь…
</td>

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

Но vertical-align работает не так.

Чем оно является на самом деле

Использование свойства vertical-align может быть разбито на три простых для понимания правила:

1. Оно применяется только к строчным элементам inline или строчным блокам inline-block.
2. Оно влияет на выравнивание самого элемента, а не его содержимого (кроме случаев, когда применяется к ячейкам таблицы).
3. Когда оно применяется к ячейке таблицы, выравнивание влияет на содержимое ячейки, а не на неё саму.

Иными словами, следующий код не даст никакого эффекта:

div {
    vertical-align:middle; /* эта строка бесполезна */
    }

Почему? Потому что <div> — это не строчный элемент и даже не строчный блок. Конечно, если вы сделаете его строчным или строчным блоком, то применение vertical-align даст желаемый эффект.

С другой стороны, при правильном применении (к строчному элементу или строчному блоку), свойство vertical-align заставит текущий элемент выровняться относительно других строчных элементов.

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

Несколько картинок

Вот картинка с пояснительным текстом, которая поможет вам понять, что происходит при вертикальном выравнивании строчных элементов:

А вот пример, в котором есть несколько строчных элементов, один из которых прижат к верху.

Ключевые слова

Несколько ключевых слов, которые можно задавать в качестве значений для свойства vertical-align:

• baseline, значение по умолчанию или «изначальное»
• bottom
• middle
• sub
• super
• text-bottom
• text-top
• top

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

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

О ключевом слове middle

К сожалению, правило vertical-align:middle не выровняет строчный элемент по середине самого высокого элемента в строке (как вы, возможно, ожидали). Вместо этого значение middle заставит элемент выровняться по середине высоты гипотетической строчной буквы «x» (так же называемой x-height). Потому, мне кажется, что это значение на самом деле должно называться text-middle, чтобы стало понятно, какой будет результат.

Взгляните на пример, где я увеличил размер шрифта так, чтобы размер x-height стал гораздо больше. После этого станет понятно, что значение middle не получится использовать очень часто.

Числовые значения

Возможно, вы не знали о том, что vertical-align принимает числовые и процентные значения. Однако это так, и вот примеры их использования:

input {
    vertical-align:100px;
    }
span {
    vertical-align:50%;
    }
img {
    vertical-align:-300px;
    }

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

Заключение

Если в одной фразе подводить итог о том, как использовать это традиционно неправильно понимаемое свойство, я бы сказал:

Свойство vertical-align работает только со строчными элементами или строчными блоками и ячейками таблицы. В случае применения не к ячейкам таблицы, оно действует на сам элемент, а не на его содержимое.

Перевод оригинальной статьи «Understanding CSS’s vertical-align Property» Луиса Лазариса (Louis Lazaris), опубликованной на сайте «Impressive Webs».

Перевод выполнил Андрей Мотошин.

Основы

Давайте обратимся к спецификации:

Атрибут contenteditable обладает фиксированным набором значений, он может быть пустой строкой, true или false. Пустая строка или true обозначают, что элемент доступен для редактирования. false обозначает, что элемент недоступен для редактирования. Есть еще третье состояние — inherit, это значение атрибута по умолчанию и оно означает, что значение наследуется от родительского элемента.

— WHATWG

В основном, атрибут contenteditable должен был обеспечивать работу WYSIWYG-редакторов. Скорее всего, вы встречали его в инструментах подобных Symphony или на cайтах вроде Flickr, где вы начинаете редактировать материалы, просто кликнув в определенную область.

Как упоминалось выше, contenteditable может быть в трёх возможных состояниях:

1. contenteditable="" или contenteditable="true" означает, что элемент доступен для редактирования
2. contenteditable="false" означает, что элемент недоступен для редактирования
3. contenteditable="inherit" означает, что элемент доступен для редактирования в случае, если его непосредственный родитель доступен для редактирования. Это значение атрибута по умолчанию.

Когда вы добавляете элементу атрибут contenteditable, браузер делает его доступным для редактирования. Кроме того, все потомки этого элемента также становятся доступны для редактирования, если атрибут contenteditable у них явно не установлен в false.

Пример кода

<div id="example-one" contenteditable="true">
    <style scoped>
        #example-one {
            margin:12px 0;
            }
        #example-one[contenteditable="true"] {
            padding:10px;
            outline:3px dashed #CCC;
            }
        #example-one[contenteditable="true"]:hover {
            outline:3px dashed #2B8BAD;
            }
    </style>
    <p>Всё что находится в этом блоке, доступно для редактирования в браузерах, поддерживающих <code>HTML5</code>. Давайте, попробуйте: кликните для начала редактирования.</p>
</div>

Демонстрация

Вот два простых примера, показывающие работу contenteditable:

Пример №1

Редактирование текста

Я использовал CSS для создания оформления, показывающего, что текст доступен для редактирования. Обратите внимание на ориентированное на будущее использование <style scoped>, которое описано в моей предыдущей статье.

Пример №2

Крис Койер рассказывал на CSS-Tricks, что вы можете позволить вашим пользователям редактировать CSS в реальном времени, так как <style> элемент имеет display:none по умолчанию, но ведь значение можно изменить на block.

Попробуйте отредактировать CSS, приведенный ниже:

Редактирование таблицы стилей

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

Поддержка атрибута contenteditable браузерами на удивление хороша:

Поддержка браузерами свойства contenteditable

Должен отметить, что появлением и отличной поддержкой атрибута мы обязаны IE 5.5, хотя на самом деле ранний вариант contenteditable был разработан и внедрен Microsoft в июле 2000 года.

Более подробную таблицу совместимости можно увидеть тут: When Can I Use.

Сохранение изменений

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

В зависимости от сложности блока ваш код может отлавливать нажатие Enter (код 13) для сохранения изменения и Esc (код 27) для их отмены.

Когда пользователь нажимает Enter (предполагаем, что редактируем однострочные данные), получаем innerHTML редактируемого блока и посылаем AJAX-запрос с изменениями на сервер.

Простой пример можно увидеть тут: Сохранение данных из элемента с сontenteditable при помощи AJAX.

— Реми Шарп

Заключение

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

Атрибут contenteditable — один из самых малоизвестных, но могу поспорить, что вы будете использовать его чаще, чем думаете.

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

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

Читать дальше

• Что такое contenteditable?
• Разворачиваем изображения с помощью HTML5 contenteditable

Перевод оригинальной статьи «The contenteditable attribute» Джека Осборна (Jack Osborne), опубликованной на сайте «HTML5 Doctor».

Перевод выполнил Антон Немцев (SilentImp).

	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.

Заключение

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