Если вы предполагаете увидеть здесь руководство по использованию интерфейсов прикладного программирования (API) HTML5, то я хочу перефразировать высказывание из одного общеизвестного вестерна и сказать: «Я не ваш Хаклберри».
Я собираюсь рассмотреть с вами «словарную» часть HTML5, то есть семантику этого языка. Если конкретнее, то способ использования новых элементов HTML5 для описания содержимого, помещаемого в разметку. Основная часть содержимого главы не имеет прямого отношения к адаптивному веб-дизайну. Но HTML является основой, на которой строятся все веб-проекты и приложения. А кому же не хочется возводить свое здание на самом крепком из фундаментов?
К тому же вас может заинтересовать, что представляет собой HTML5. В таком случае я скажу, что HTML5 — это всего лишь название самой последней версии HTML, языка тегов, используемого для создания веб-страниц. Сам HTML является постоянно развивающимся стандартом, предыдущая основная версия которого имела номер 4.01.
О предшествующих версиях и путях развития HTML можно узнать в «Википедии» по адресу .
совет
В настоящее время HTML5 является рекомендацией консорциума W3C. Соответствующую спецификацию можно найти по адресу /.
В этой главе будут рассмотрены следующие вопросы:
• насколько широка поддержка HTML5;
• как правильно написать начало страницы на HTML5;
• покладистость HTML5;
• новые семантические элементы;
• семантика на уровне текста;
• устаревшие функции;
• внедрение новых элементов;
• соответствие уровня доступности требованиям Руководства по обеспечению доступности веб-контента (Web Content Accessibility Guidelines (WCAG)) и Стандарта предоставления возможности полноценного использования Интернета людьми с физическими ограничениями (Web Accessibility Initiative-Accessible Rich Internet Applications (WAI-ARIA)) для повышения общей доступности веб-приложений;
• встраиваемое медиасодержимое;
• адаптивное видео и iFrames;
• замечание по поводу приоритета автономности.
примечание
В HTML5 также предоставляются конкретные инструменты для работы с формами и пользовательским вводом. Набор соответствующих функций существенно разгружает более ресурсоемкие технологии вроде JavaScript в вопросах проверки правильности заполнения форм. Хотя формы HTML5 будут рассмотрены отдельно в главе 9.
Сегодня основная масса просматриваемых мною сайтов (и все сайты, созданные моими руками) написаны с использованием HTML5, без применения старого стандарта HTML 4.01.
Новые семантические элементы HTML5 (новые элементы структуры, видео- и аудиотеги) понятны всем современным браузерам, и даже старые версии Internet Explorer (предшествующие Internet Explorer 9) могут пользоваться небольшими дополнениями (полифиллами), позволяющими выводить эти новые элементы.
Что такое полифиллы?
Термин «полифилл» придуман Реми Шарпом (Remy Sharp) как намек на заполнение трещин в старых браузерах с помощью Polyfilla (известной в США шпатлевки). То есть полифилл является своеобразной прокладкой, написанной на JavaScript и предназначенной для эффективного воспроизводства новейших функций в устаревших браузерах. Но при этом важно понимать, что полифиллы утяжеляют код. Поэтому даже возможность добавления 15 полифилльных сценариев, способных заставить Internet Explorer 6 выводить сайт на экран не хуже любых других браузеров, не означает необходимости подобного добавления.
Если нужно включить в работу структурные элементы HTML5, то я бы посоветовал обратить внимание на исходный сценарий Реми Шарпа (/) или создание заказной сборки Modernizr (). Если инструментальное средство Modernizr вам еще не попадалось или не использовалось вами, то в следующей главе ему посвящен целый раздел.
А теперь, имея в виду все вышеизложенное, рассмотрим начало страницы на HTML5 и разберемся во всех открывающих тегах и их предназначении.
Начнем с самых первых строчек документа на HTML5. Стоит здесь ошибиться, и вы будете долго удивляться, почему ваша страница не ведет себя нужным образом. Первые несколько строк должны иметь примерно следующий вид:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset=utf-8>
Разберем эти теги по отдельности. Вообще-то они не будут меняться при каждом создании веб-страницы, но, вы уж мне поверьте, узнать об их предназначении будет весьма полезно.
Объявление doctype предназначено для того, чтобы сообщить браузеру о типе имеющегося документа. Иначе он не получит необходимые ему сведения о том, как нужно распорядиться содержимым этого документа.
Наш документ открывается HTML5-объявлением doctype:
<!DOCTYPE html>
Если вам нравится использовать нижний регистр, можете записать объявление в виде <!doctype html>. Разницы никакой.
По сравнению с HTML 4.01, где в начале страницы использовалось что-то вроде
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"">
это изменение было весьма долгожданным. Прежнее объявление вызывало стойкое неприятие, и я обычно переносил его целиком с предыдущих страниц.
А вот в HTML5 объявление doctype радует своей краткостью, ограничиваясь лишь формой <!DOCTYPE html>. Интересный факт (во всяком случае, для меня): все закончилось тем, что был избран самый короткий способ сообщения браузеру о необходимости вывода страницы в стандартном режиме.
совет
Если вас интересует, что такое режим совместимости и стандартный режим, зайдите на страницу «Википедии» по адресу .
После объявления doctype открывается тег html, являющийся корневым тегом документа. В нем также используется атрибут lang, указывающий на язык документа, а после него открывается раздел <head>:
<html lang="en">
<head>
В соответствии со спецификациями W3C () атрибут lang указывает основной язык содержимого элементов и любого из атрибутов элемента, содержащего текст. Если вы не пишете страницы на английском, то лучше указать правильный код языка. Например, для японского HTML-тег должен выглядеть так: <html lang="ja">. Полный перечень языков можно найти на сайте .
В заключение указывается кодировка символов. Поскольку это пустой элемент (в котором ничего не может содержаться), закрывающий тег ему не нужен:
<meta charset="utf-8">
Для charset без веской причины для чего-нибудь другого почти всегда указывается значение utf-8. Любознательные могут найти дополнительные сведения по этому вопросу на сайте .
Помню, в школьные времена, когда порой наш учитель математики, по прозвищу Супермин (образовано от его фамилии Mean, то есть «средний», хотя на самом деле он был весьма неплохим учителем), не выходил на работу, все вздыхали с облегчением. В отличие от мистера Мина (фамилия изменена, дабы не нанести вреда) заменявший его учитель был покладистым и дружелюбным человеком. Он сидел тихо и обходился без крика и постоянных назиданий. Он не требовал тишины во время занятий и особо не зацикливался на нашем поведении, если мы вникали в способы решения предлагаемых им задач. Для него имели смысл наши ответы и объяснение того, как мы к ним пришли. Если бы HTML5 был учителем математики, он был бы именно таким вот покладистым по характеру. И я сейчас поясню эту странную аналогию.
Если уделяется особое внимание способу написания кода, то обычно применяются символы в нижнем регистре, значения атрибутов заключаются в кавычки, а для сценариев и таблиц стилей используется объявление типа (type). Например, вполне возможно, что для ссылки на таблицу стилей используется следующая запись:
<link href="CSS/main.css" rel="stylesheet" type="text/css" />
HTML5 не требует подобной строгости, ему вполне достаточно и такой записи:
<link href=CSS/main.css rel=stylesheet >
Заметили? В теге отсутствует закрывающий слеш, нет кавычек вокруг значений атрибутов и нет объявления типа. Но покладистому HTML5 этого и не надо. Второй пример так же работоспособен, как и первый.
Такой нестрогий синтаксис применяется по всему документу, а не только в ссылках на ресурсы. Например, если хотите, можете указать на div-контейнер следующим образом:
<div id=wrapper>
И это будет вполне приемлемый код HTML5. То же самое касается вставки изображения:
<img SRC=frontCarousel.png aLt=frontCarousel>
Это также вполне приемлемый код HTML5. Без закрывающего тег слеша, без кавычек и с использованием вперемешку символов в нижнем и верхнем регистре. Можно даже опустить такие элементы, как открывающий тег <head>, и страница все равно будет полноценной. Что бы сказали об этом приверженцы XHTML?
совет
Хотите сократить код до норм, допустимых в HTML5? Присмотритесь к набору HTML5 Boilerplate (/). Это готовый файл HTML5, выдержанный в лучших традициях этого языка, включающий свойственные ему стили, полифиллы и такие дополнительные инструментальные средства, как Modernizr. Просматривая код, можно почерпнуть множество полезных подсказок, кроме того, можно получить заказную сборку шаблона, соответствующую именно вашим потребностям. Настоятельно рекомендую!
Лично мне нравится записывать разметку в стиле языка XHTML. Это означает использование закрывающих тегов, заключение значений атрибутов в кавычки и приверженность к постоянному использованию одного и того же регистра символов. Можно утверждать, что избавление от подобной практики позволит сэкономить несколько байтов данных, но для экономии существует ряд инструментальных средств (при необходимости с их помощью могут быть убраны все ненужные символы и данные). Я же хочу, чтобы моя разметка была как можно разборчивее, и призываю всех поступать точно так же. Я считаю, что нельзя стремиться к краткости кода в ущерб его ясности.
Поэтому я полагаю, что при написании документов HTML5 вы можете создавать понятный и удобочитаемый код и в то же время пользоваться экономией, предлагаемой HTML5. К примеру, для ссылки на CSS я бы воспользовался следующим кодом:
<link href="CSS/main.css" rel="stylesheet"/>
Я сохранил слеш, закрывающий тег и кавычки, но обошелся без атрибута type. В данном случае нужно выдерживать ту меру, которая для вас наиболее комфортна. HTML5 не станет на вас кричать, размахивать вашей разметкой перед всем классом и ставить вас в угол, как нерадивого ученика, не справившегося с заданием (неужели все это было только в моей школе?). Но вам хочется написать свою разметку на отлично.
Думаете, я шучу? Хочу, чтобы вы именно сейчас узнали, что если станете записывать код без кавычек вокруг значений атрибутов и не закрывать теги, то заслужите мое молчаливое осуждение.
совет
Несмотря на свободный синтаксис HTML5, никогда не помешает проверить допустимость разметки. Правильная разметка обладает большей доступностью. Для этих целей был создан механизм проверки на соответствие стандартам W3C, который можно найти на сайте /.
Ну хватит, наверное, мне уже осуждать новаторов разметки. Посмотрим на те преимущества, которые дает нам HTML5.
В HTML5 теперь можно сильно сэкономить, заключив в тег <a> сразу несколько элементов (и давно пора было именно так и сделать). Раньше, чтобы соблюсти правила разметки, необходимо было заключать каждый элемент в собственный тег <a>. Рассмотрим, к примеру, следующий код HTML 4.01:
<h2><a href="index.html">The home page</a></h2>
<p><a href="index.html">This paragraph also links to the home page</
a></p>
<a href="index.html"><img src="home-image.png" alt="home-slice" /></a>
В HTML5 можно избавиться от всех индивидуальных тегов <a> и заключить всю группу в один такой тег:
<a href="index.html">
<h2>The home page</h2>
<p>This paragraph also links to the home page</p>
<img src="home-image.png" alt="home-slice" />
</a>
Но следует помнить об одном вполне понятном ограничении: нельзя заключать один тег <a> в другой такой же тег (просто потому, что это глупо) или в другой интерактивный элемент, например в кнопку button (поскольку это глупо вдвойне!), нельзя также заключать в тег <a> форму (почему — догадайтесь сами).
Если посмотреть, как определяется слово «семантика» в словаре OS X, мы увидим следующее:
«Раздел лингвистики и логики, занимающийся определением смысла».
Для нас семантика — это придание смысла разметке. Почему так важен этот процесс? Буду рад, если именно это вы и собирались спросить.
Большинство сайтов придерживаются довольно стандартных структурных соглашений, при которых типичными областями являются заголовок (header), подвал (footer), боковая панель (sidebar), панель навигации (navigation bar) и т. д. Мы, как разработчики веб-приложений, зачастую называем используемые div-контейнеры так, чтобы конкретнее обозначить эти области (например, class="Header"). Но что касается использования самого кода, любой пользовательский агент (браузер, программа для чтения содержимого экрана, поисковая машина и т. д.), просматривающий этот код, не может с уверенностью определить предназначение каждого из этих div-элементов. Пользователям вспомогательных технологий также было бы трудно отличить один div-контейнер от другого. В HTML5 для решения этой задачи имеются новые семантические элементы.
примечание
Полный перечень HTML5-элементов можно получить абсолютно свободно, если указать в браузере адрес .
Я не стану рассматривать здесь абсолютно все новые элементы, ограничусь только теми из них, которые, на мой взгляд, наиболее полезны или интересны в повседневной работе с использованием адаптивного веб-дизайна. Перейдем к их изучению.
В HTML5 долго не было элемента для выделения основного содержимого страницы. Внутри тела веб-страницы им будет обозначаться элемент, в котором находится основной блок содержимого.
Вначале утверждалось, что содержимое, находящееся за пределами одного из прочих новых семантических элементов HTML5, будет по принципу обратной логики принадлежать основному содержимому. К счастью, спецификация изменилась и теперь у нас есть более описательный способ группировки основного содержимого, называемый тегом <main>.
Что бы ни заключалось в этот элемент, основное содержимое страницы или основной раздел веб-приложения, он послужит для группировки всего основного. Вот как звучит весьма полезное положение из спецификации:
«Область основного содержимого документа включает уникальную для этого документа информацию и исключает содержимое, повторяющееся в наборе документов, такое как имеющиеся на сайте навигационные ссылки, информация об авторском праве, логотипы и баннеры сайта и формы для поиска данных (если только основной функцией документа или приложения не является именно поиск данных)».
Стоит также отметить, что на странице не может быть более одной основной области (в конечном счете у вас же не может быть двух частей основного содержимого) и она не может быть использована в качестве потомка некоторых других семантических элементов HTML5, таких как article, aside, header, footer, nav или header. А вот они могут находиться внутри элемента main.
примечание
Официальные положения, касающиеся элемента main, можно найти на сайте .
Элемент <section> используется для определения универсального раздела документа или приложения. Например, можно создавать разделы, включающие содержимое: один раздел для контактной информации, еще один раздел для канала новостей и т. д. Важно понимать, что этот элемент не предназначен для придания стилевого оформления. Если нужно поместить элемент в контейнер просто для его стилевой настройки, можно, как и прежде, использовать div-элемент.
При работе с веб-приложениями я предпочитаю использовать section в качестве элемента-контейнера для визуальных компонентов, поскольку он предоставляет простой способ обозначения начала и конца компонентов в разметке.
Для себя можно также решить, будет ли элемент section использоваться там, где разделяемое содержимое имеет внутри себя естественный заголовок (например, h1). Если такого заголовка нет, то лучше, наверное, будет воспользоваться div-контейнером.
примечание
Чтобы посмотреть, что об элементе <section> говорится в спецификации W3C HTML5, обратитесь по адресу .
Элемент <nav> используется в качестве контейнера основных навигационных ссылок на другие страницы или фрагменты внутри той же самой страницы. Он не предназначен исключительно для использования в подвалах (хотя может применяться и там) и им подобных структурах, где обычно располагаются ссылки на другие страницы.
Если вы обычно размечаете свои элементы навигации в виде неупорядоченного списка (<ul>) и набора списочных тегов (li), то вместо этого вам могут больше подойти элемент nav и несколько вложенных тегов <a>.
примечание
Чтобы посмотреть, что об элементе <nav> говорится в спецификации W3C HTML5, перейдите в браузере по адресу .
Элемент <article> вполне можно перепутать с элементом <section>. Прежде чем понять разницу между ними, мне пришлось несколько раз перечитать спецификацию. Переложение спецификации в моем исполнении звучит следующим образом: элемент <article> используется в качестве контейнера для законченных фрагментов содержимого. При структурировании страницы нужно задаться вопросом: можно ли содержимое, которое вы собираетесь использовать внутри элемента <article>, переместить на другой сайт в виде цельного фрагмента, без потери завершенности? Можно ли также представить содержимое, рассматриваемое для помещения внутрь элемента <article>, как отдельную статью для RSS-канала? Вполне очевидными примерами содержимого, пригодного для помещения в элемент <article>, могли бы стать публикации в блогах или новостные сообщения. Нужно понимать, что вложенные элементы <article> прежде всего имеют отношение к внешним элементам <article>.
примечание
Чтобы узнать, что говорится в спецификации W3C HTML5 об элементе <article>, нужно зайти на сайт .
Элемент <aside> используется для содержимого, которое косвенно касается окружающего его контента. На практике я часто пользуюсь им для боковых панелей (когда в них содержится подходящий контент). Этот элемент также считается подходящим для цитат, рекламных вставок и групп элементов навигации. В основном в качестве содержимого элемента aside вполне подойдет все, что не имеет прямого отношения к основному содержимому. Полагаю, что при использовании сайта электронной торговли первейшими кандидатами для <aside> вполне могут стать области типа «клиенты, купившие этот товар, приобрели также…».
примечание
Дополнительные сведения из спецификации W3C HTML5 относительно элемента <aside> можно найти по адресу .
В спецификации, относящейся к элементу <figure>, говорится следующее:
«...таким образом, он может использоваться для аннотации иллюстраций, диаграмм, фотографий листингов кода и т. д.».
С его помощью корректуру части разметки из первой главы можно выполнить следующим образом:
<figure class="MoneyShot">
<img class="MoneyShotImg" src="img/scones.jpg" alt="Incredible scones" />
<figcaption class="ImageCaption">Incredible scones, picture from
Wikipedia</figcaption>
</figure>
Как видите, элемент <figure> используется в качестве контейнера этого небольшого законченного блока. Внутри него, чтобы предоставить подпись для родительского элемента <figure>, используется элемент <figcaption>.
Этот элемент пригодится тогда, когда изображениям или коду нужны небольшие сопроводительные подписи, которые не будут соответствовать основному тексту содержимого.
примечание
Спецификацию, касающуюся элемента <figure>, можно найти по адресу .
А спецификация на <figcaption> находится по адресу .
Вам, наверное, не раз хотелось создать на странице простой открывающийся и закрывающийся виджет, то есть фрагмент краткого изложения, по щелчку на котором открывается панель с дополнительной информацией. HTML5 облегчает создание такой модели с помощью элементов <details> и <summary>.
Рассмотрим следующую разметку (для ее практической проверки можно открыть пример, находящийся в файле example3.html, входящем в каталог кода для данной главы):
<details>
<summary>I ate 15 scones in one day</summary>
<p>Of course I didn't. It would probably kill me if I did. What a
way to go. Mmmmmm, scones!</p>
</details>
Этот файл, открытый в браузере Chrome без добавления какого-либо стиля, покажет изначально только текст элемента summary.
При щелчке на любом месте текста элемента <summary> открывается панель. При повторном щелчке эта панель закрывается. Если нужно чтобы изначально панель была открыта, к элементу <details> можно добавить атрибут open:
<details open>
<summary>I ate 15 scones in one day</summary>
<p>Of course I didn't. It would probably kill me if I did. What a
way to go. Mmmmmm, scones!</p>
</details>
Поддерживающие данные элементы браузеры обычно добавляют некоторое исходное стилевое оформление, чтобы указать на возможность открытия панели. В данном случае в браузере Chrome (а также Safari) будет выведен темный треугольник открытия. Чтобы выключить это оформление, нужно воспользоваться фирменным для WebKit псевдоселектором:
summary::-webkit-details-marker {
display: none;
}
Разумеется, этот же селектор можно использовать для другого стилевого оформления маркера.
В данный момент способ анимации открытия и закрытия отсутствует. Не существует также (без использования кода JavaScript) способа закрытия других панелей подробностей (отображаемых на том же уровне) при открытии какой-нибудь другой панели. Я не уверен в том, что какое-либо из этих пожеланий когда-нибудь будет (или должно быть) воплощено в жизнь. Это следует воспринимать в основном как способ подсказать, что можно было бы сделать с помощью свойства display: none;, переключаемого с помощью кода JavaScript.
К сожалению, на момент работы над этим текстом (в середине 2015 года) поддержка этих элементов в Firefox или Internet Explorer отсутствовала (они просто выводили оба элемента в качестве линейных). Есть, правда, полифиллы (), но я надеюсь, что вскоре появится и полноценная поддержка.
На практике элемент <header> может использоваться для области титульных данных заголовка сайта. Он также может использоваться в качестве введения в остальное содержимое, например в раздел, заключенный в элемент <article>. На одной странице его можно использовать столько раз, сколько нужно (к примеру, на вашей странице элемент <header> может быть внутри каждого элемента <section>).
примечание
Узнать, что говорится об элементе <header> в спецификации W3C HTML5, можно по адресу .
Элемент <footer> нужно использовать для содержания информации о разделе, в котором он находится. В нем могут содержаться ссылки на другие документы или, к примеру, информация об авторском праве. Если нужно, то он, как и элемент <header>, может использоваться на одной странице многократно. Например, его можно использовать для подвала блога, а также как подвальную часть в отдельной публикации блога. Но в спецификации объясняется, что контактная информация автора публикации в блоге должна вместо него помещаться в элемент <address>.
примечание
Все, что говорится в спецификации W3C HTML5 об элементе <footer>, можно найти по адресу .
Элемент <address> должен использоваться исключительно для разметки контактной информации для своего ближайшего предка, <article> или <body>. Чтобы не возникало путаницы, следует иметь в виду, что он не предназначен для размещения почтовых адресов и тому подобной информации (если только они действительно не будут представлять собой контактные адреса для рассматриваемого содержимого). Почтовые адреса и другая произвольная контактная информация должна заключаться в старые добрые теги <p>.
Я не сторонник использования элемента <address>, поскольку по собственному опыту знаю, что было бы намного полезнее размещать в собственном элементе именно физический адрес, но это мое личное мнение. Надеюсь, вы сможете найти больше смысла в применении данного элемента.
примечание
Чтобы узнать, что еще говорится в спецификации W3C HTML5 об элементе <address>, обратитесь по адресу .
Только в последнее время я узнал, что для разметки заголовков и подзаголовков использовать теги <h1> — <h6> не рекомендуется. Я имею в виду следующее:
<h1>Scones:</h1>
<h2>The most resplendent of snacks</h2>
А вот цитата из спецификации HTML5:
«Элементы <h1> — <h6> не должны использоваться для разметки подзаголовков, субтитров, альтернативных названий и слоганов, если только они не рассматриваются в качестве заголовка для нового раздела или подраздела».
И это еще не самое неоднозначное положение в спецификации!
Как же нам поступать в подобных случаях? В спецификации этому посвящен целый раздел (). Лично я отдавал предпочтение устаревшему элементу <hgroup>, но, к сожалению, этот корабль уже уплыл (упоминание о нем можно найти в разделе «Устаревшие функции HTML»). Итак, чтобы последовать совету, данному в спецификации, предыдущий пример должен быть переписан следующим образом:
<h1>Scones:</h1>
<p>The most resplendent of snacks</p>
Кроме уже рассмотренных элементов, определяющих структуру и помогающих сгруппировать данные, в HTML5 предусматривается ряд тегов, которые ранее назывались линейными элементами. Теперь в спецификации HTML5 на эти элементы ссылаются как на элементы семантики на текстовом уровне (). Рассмотрим несколько примеров общего характера.
Исторически сложилось так, что элемент <b> означает «выделить жирным шрифтом» (). Это было еще в те давние времена, когда частью разметки считался и выбор стиля. Но теперь официально этот элемент можно использовать только в качестве стилевой привязки в коде CSS, поскольку в текущей спецификации HTML5 об элементе <b> говорится следующее:
«Элемент <b> является представлением фрагмента текста, на который обращается внимание в потребительском смысле, без придания ему какой-либо особой важности и без применения другой голосовой интонации; это могут быть, к примеру, выделяемые в документе ключевые слова, наименования товаров в обзоре, побуждающие к действию слова в интерактивном, управляемом текстом программном средстве или же первый абзац статьи».
Хотя сейчас этому элементу не придается никакого конкретного смысла, поскольку он относится к текстовому уровню, он не предназначен для заключения в него большой группы элементов разметки, поскольку для этой цели следует применять div-элемент. Следует также иметь в виду, что поскольку он исторически использовался для выделения текста жирным шрифтом, то, если вам нужно, чтобы содержимое, помещенное внутрь тега <b>, не выводилось на экран жирным шрифтом, придется переключить свойство font-weight в CSS.
Каюсь, я часто пользовался элементом <em> в качестве средства стилевого оформления. Мне следует пересмотреть свои позиции, приняв во внимание определение из HTML5:
«Элемент <em> акцентирует внимание на своем содержимом».
Следовательно, пока вы не хотите акцентировать чье-либо внимание на заключаемом в элемент содержимом, пользуйтесь тегом <b> или там, где это уместно, тегом <i>.
В спецификации HTML5 про элемент <i> говорится следующее:
«...выделяемый или произносимый с другой интонацией отрывок текста или же выделенный качественно — как выпадающий из общего ряда повествования»
Достаточно сказать, что он не используется просто для выделения чего-либо курсивным шрифтом. Например, им можно воспользоваться для разметки в строке текста какого-либо странного названия:
<p>However, discussion on the hgroup element is now frustraneous as
it's now gone the way of the <i>Raphus cucullatus</i>.</p>
примечание
В HTML5 существует масса других семантических тегов текстового уровня. Чтобы просмотреть все эти теги, обратитесь к соответствующему разделу спецификации по адресу .
Кроме атрибутов языка в ссылках на сценарии, есть и другие части HTML, которыми вы, возможно, привыкли пользоваться и которые теперь в HTML5 считаются устаревшими. Важно понимать, что в HTML5 есть две разновидности устаревших функций: соответствующие и несоответствующие. Соответствующие функции сохраняют свою работоспособность, но в системах проверки в отношении их будут выдаваться предупреждения. На практике следует по возможности избегать их применения, но если все же они будут использоваться, от этого небеса не рухнут на землю. Несоответствующие функции могут по-прежнему влиять на отображение данных в конкретных браузерах, но если их использовать, то можно прослыть весьма рисковым человеком и лишиться выходных!
Перечень устаревших и несоответствующих функций весьма обширен. Признаться, многими из них я никогда не пользовался (а некоторые даже никогда не видел!). Возможно, у вас на них будет аналогичная реакция. Но если интересно, полный перечень устаревших и несоответствующих функций можно найти по адресу . Из наиболее примечательных устаревших и несоответствующих функций можно назвать strike, center, font, acronym, frame и frameset.
Есть также функции, фигурировавшие в ранних предварительных версиях HTML5, которые теперь попали в число отвергнутых. В качестве примера можно привести hgroup. Изначально предполагалось использовать этот тег в качестве контейнера для групп заголовков, то есть h1 как основной заголовок и h2 как подзаголовок могли помещаться внутрь элемента hgroup. Но теперь дискутировать по поводу элемента hgroup совершенно бесполезно, поскольку он пошел по пути вымершего Raphus cucullatus (если хотите узнать, кто это, воспользуйтесь Google).
Настало время применить некоторые из только что рассмотренных элементов на практике. Вернемся к примеру из главы 1. Если сравнить разметку, показанную ниже, с исходной разметкой из первой главы (напоминаю, что все примеры можно загрузить с сайта или из репозитория GitHub), то можно увидеть те места, где применены рассмотренные нами новые элементы:
<article>
<header class="Header">
<a href="/" class="LogoWrapper"><img src="img/SOC-Logo.png"
alt="Scone O'Clock logo" /></a>
<h1 class="Strap">Scones: the most resplendent of snacks</h1>
</header>
<section class="IntroWrapper">
<p class="IntroText">Occasionally maligned and misunderstood; the
scone is a quintessentially British classic.</p>
<figure class="MoneyShot">
<img class="MoneyShotImg" src="img/scones.jpg" alt="Incredible
scones" />
<figcaption class="ImageCaption">Incredible scones, picture from
Wikipedia</figcaption>
</figure>
</section>
<p>Recipe and serving suggestions follow.</p>
<section class="Ingredients">
<h3 class="SubHeader">Ingredients</h3>
</section>
<section class="HowToMake">
<h3 class="SubHeader">Method</h3>
</section>
<footer>
Made for the book, <a href="
web design with HTML5 and CSS3'</a> by <address><a href="://
benfrain">Ben Frain</a></address>
</footer>
</article>
Осмысленный выбор элементов. Чтобы сконцентрироваться на структуре, я убрал существенный объем внутреннего содержимого. Надеюсь, вы согласитесь с тем, что отличить различные разделы разметки друг от друга весьма несложно. Но теперь мне хотелось бы дать один довольно прагматичный совет: мир не рухнет, если вы не станете всякий раз выбирать правильный элемент для каждой отдельно взятой ситуации. Например, какой бы из элементов в предыдущем примере я ни применил, <section> или <div>, это не выразилось бы в каких-то реальных последствиях. Если вместо предписанного к использованию элемента <i> используется <em>, я не считаю это преступлением против человечества и ребята из W3C не откроют на вас охоту и не станут вас очернять за неправильный выбор. Просто руководствуйтесь здравым смыслом. И тем не менее, если есть возможность смыслового использования таких элементов, как <header> и <footer>, их применение обеспечит большую доступность вашего кода для понимания.
Со времени написания первого издания данной книги (2011 и 2012 годы) консорциум W3C добился многого в деле упрощения для разработчиков написания более доступных веб-страниц.
Руководство WCAG существует с целью предоставления «единого общего стандарта для доступности веб-контента, отвечающего на международной основе нуждам физических лиц, организаций и правительств».
Когда речь заходит о более простых веб-страницах (в противовес единой странице веб-приложений и им подобных средств), имеет смысл сконцентрироваться на руководстве WCAG. В нем предлагается целый ряд (в основном вполне разумных) рекомендаций по обеспечению доступности вашего веб-контента. Каждая рекомендация оценивается по уровням соответствия: A, AA или AAA. Дополнительные сведения об этих уровнях можно найти по адресу .
Возможно, окажется, что вы уже придерживаетесь многих из рекомендаций, например, в плане предоставления альтернативного текста для изображений. Краткое изложение рекомендаций можно получить по адресу , после чего создать свой собственный краткий контрольный лист-справочник по образцу, показанному на сайте /.
Я призываю всех потратить пару часов на изучение списка. Многие рекомендации совсем не трудно выполнить, предоставив тем самым реальные преимущества пользователям.
Стандарт WAI-ARIA предназначен главным образом для решения проблем доступности динамического контента на веб-странице. Он предоставляет для специализированных виджетов (динамических разделов в веб-приложениях) средства описания ролей, состояний и свойств, чтобы они стали узнаваемыми и годными к использованию теми пользователями, которые применяют вспомогательные технологии.
Например, если выведенный на экран виджет показывает постоянно обновляемые биржевые котировки, то как незрячий пользователь получит доступ к странице, чтобы узнать об этом? Стандарт WAI-ARIA пытается решать проблемы подобного рода.
Не используйте роли для семантических элементов. Ранее рекомендовалось добавлять значимые роли к заголовкам и подвалам:
<header role="banner">A header with ARIA landmark banner role</header>
Но теперь это считается излишним. Если заглянуть в спецификацию для любого из ранее перечисленных элементов, там есть специально выделенный раздел разрешенных значений ARIA-атрибута role — Allowed ARIA role attributes. В качестве примера можно привести разъяснения из раздела элемента:
«Разрешенные значения ARIA-атрибута role: region role (по умолчанию не устанавливается), alert, alertdialog, application, contentinfo, dialog, document, log, main, marquee, presentation, search или status».
Основной частью здесь является «role (по умолчанию не устанавливается)». Это означает, что явное добавление этой ARIA-роли к элементу не имеет никакого смысла, поскольку она подразумевается самим элементом. Теперь это поясняется примечанием к спецификации:
«В большинстве случаев установка ARIA-атрибута role и/или атрибута aria-*, соответствующего исходной подразумеваемой ARIA-семантике, является излишней и не рекомендуется, поскольку эти свойства уже установлены браузером».
Самое простое, что можно сделать с прицелом на применение вспомогательных технологий, — это пользоваться везде, где это возможно, правильными элементами. Элемент <header> окажется намного полезнее, чем div class="Header". Точно так же, если у вас на странице есть кнопка, воспользуйтесь элементом <button>, а не элементом <span> или другим элементом, стилизованным под кнопку. Готов признать, что элемент <button> не всегда позволяет применять конкретное стилевое оформление (его, к примеру, нельзя настроить с помощью инструкций display: table-cell или display: flex), но тогда выберите следующий более подходящий элемент, в качестве которого обычно выступает тег <a>.
ARIA не ограничивается одной лишь ориентацией в отношении ролей. Развивать стандарт помогают полный перечень ролей и краткое описание их пригодности к использованию, доступные по адресу .
Чтобы проще было разобраться в теме, я также рекомендую прочитать книгу Хейдона Пикеринга (Heydon Pickering) Apps For All: Coding Accessible Web Applications (доступна на сайте ).
совет
Можно бесплатно протестировать свою конструкцию с помощью невизуального доступа к Рабочему столу (non-visual desktop access (NVDA)).
Если разработка ведется под платформу Windows и возникает желание протестировать конструкции, доработанные согласно стандарту ARIA с помощью экранного диктора, можно совершенно свободно воспользоваться средством NVDA. Оно доступно по адресу /.
Google теперь также поставляет бесплатное инструментальное средство для разработки доступных сайтов под названием Accessibility Developer Tools, предназначенное для браузера Chrome (доступны также кросс-платформенные версии), которое также стоит проверить в деле.
Существует также постоянно пополняемый арсенал средств, помогающих быстро протестировать ваши собственные конструкции на использование их людьми с нарушенным цветовосприятием. Например, по адресу / находится Mac-приложение, позволяющее переключать типы нарушения цветовосприятия и просматривать предварительные результаты на плавающей палитре.
И наконец, OS X также включает утилиту VoiceOver, позволяющую тестировать ваши веб-страницы.
Надеюсь, краткое введение в WAI-ARIA и WCAG обеспечило вам достаточный объем информации, чтобы появилось больше идей о том, как можно подойти к поддержке вспомогательных технологий. Возможно, добавление поддержки таких технологий к вашим следующим проектам на HTML5 окажется проще, чем вы думали.
И в заключение укажу на еще один ресурс, касающийся всех вопросов доступности, содержащий массу полезных ссылок и советов, находящихся на домашней странице проекта A11Y по адресу /.
Многие услышали об HTML5, когда Apple отказалась добавлять поддержку для Flash на свои iOS-устройства. Технология Flash получила на рынке доминирующее положение (некоторые утверждают, что она захватила рынок) в качестве дополнительного модуля для обслуживания видео в браузере. Но вместо использования технологии, являющейся собственностью компании Adobe, Apple в вопросах вывода на экран сложного медиасодержимого решила положиться на HTML5. Наряду с тем что в HTML5 был достигнут неплохой прогресс в данной области, публичная поддержка HTML5 со стороны Apple дала этой версии языка могучий толчок и помогла ее медиаинструментам стать привлекательными для широких кругов потребителей.
Несложно предположить, что Internet Explorer 8 и более ранние версии этого браузера не поддерживают аудио и видео HTML5. Большинство других современных браузеров (Firefox 3.5+, Chrome 4+, Safari 4, Opera 10.5+, Internet Explorer 9+, iOS 3.2+, Opera Mobile 11+, Android 2.3+) справляются с этой задачей вполне успешно.
Работать с видео и аудио в HTML5 довольно просто. Единственной реальной трудностью, связанной с HTML5-медиа, было перечисление альтернативных медиаформатов, поскольку различные браузеры поддерживают разные форматы файлов. Сегодня повсеместной поддержкой как на обычных, так и на мобильных платформах пользуется формат MP4, что делает включение медиаинформации в ваши веб-страницы посредством HTML5 простым и легким. Вот пример ссылки на видеофайл на вашей странице из разряда «проще некуда»:
<video src="myVideo.mp4"></video>
В HTML5 со всей трудной работой справляется один-единственный тег <video></video> (или <audio></audio> для аудио). Между открывающим и закрывающим тегами можно вставить текст, информирующий пользователей при возникновении проблем. Существуют также дополнительные атрибуты, которые обычно хочется добавить, например, высота и ширина. Добавим их:
<video src="myVideo.mp4" width="640" height="480">What, do you mean
you don't understand HTML5?</video>
Теперь, если добавить предыдущий фрагмент кода на страницу и посмотреть на его работу в Safari, видео появится, но без элементов управления его проигрыванием. Для получения исходных элементов управления проигрыванием нужно добавить атрибут controls. Мы также можем добавить атрибут autoplay (что не рекомендуется делать, поскольку всем известно, с каким раздражением воспринимаются видео с автовоспроизведением). Все это демонстрируется в следующем фрагменте кода:
<video src="myVideo.mp4" width="640" height="480" controls autoplay>
What, do you mean you don't understand HTML5?</video>
Результат выполнения этого фрагмента показан на следующей копии экрана.
В число прочих атрибутов входят preload для управления предварительной загрузкой медиа (те, кто пользовался ранними версиями HTML5, заметят, что preload пришел на смену autobuffer), loop для повторения видео и poster для определения кадра заставки для видео. Он пригодится при ожидаемой задержке воспроизведения видео (или когда какое-то время будет затрачиваться на буферизацию). Для применения атрибута достаточно вставить его в тег. Вот как выглядит пример, включающий все эти атрибуты:
<video src="myVideo.mp4" width="640" height="480" controls autoplay
preload="auto" loop poster="myVideoPoster.png">What, do you mean you
don't understand HTML5?</video>
Резервная возможность для старых браузеров. Тег <source> позволяет при необходимости предоставлять резервные возможности. Например, наряду с предоставлением версии видео в формате MP4 при желании обеспечить удобную замену для Internet Explorer 8 и более ранних версий можно добавить резервное видео в формате Flash. Кроме того, если у пользователя в браузере нет подходящей технологии проигрывания, можно предоставить ссылки на скачивание самих файлов. Рассмотрим следующий пример:
<video width="640" height="480" controls preload="auto" loop
poster="myVideoPoster.png">
<source src="video/myVideo.mp4" type="video/mp4">
<object width="640" height="480" type="application/x-shockwave-
flash" data="myFlashVideo.SWF">
<param name="movie" value="myFlashVideo.swf" />
<param name="flashvars" value="controlbar=over&image=myVideo
Poster.jpg&file=myVideo.mp4" />
<img src="myVideoPoster.png" width="640" height="480"
alt="__TITLE__"
title="No video playback capabilities, please download the
video below" />
</object>
<p><b>Download Video:</b>
MP4 Format: <a href="myVideo.mp4">"MP4"</a>
</p>
</video>
Этот пример кода находится в файле example2.html, который, как и пробный видеофайл в формате MP4, содержится в папке с кодом к данной главе.
Тег <audio> работает по таким же принципам и с такими же атрибутами (исключая width, height и poster). Основное отличие этих двух тегов друг от друга заключается в том обстоятельстве, что у <audio> отсутствует область проигрывания визуального содержимого.
Мы уже видели, что поддержка устаревших браузеров неизменно приводит к увеличению объема кода. То, что начиналось с одной или двух строк тега <video>, заканчивается в конечном итоге десятью и более строками (и дополнительным Flash-файлом), и все это ради того, чтобы осчастливить пользователей устаревших версий Internet Explorer! Что касается меня, то я обычно радуюсь возможности отказаться от отката к Flash-технологии в погоне за меньшим объемом используемого кода, но все же бывают разные обстоятельства.
Теперь единственной проблемой со столь понравившейся нам реализацией видео в HTML5 является отсутствие в ней адаптивности. И действительно, в книге приведен пример, который не реагирует на изменение условий просмотра.
К счастью, для встроенного HTML5-видео все это можно легко исправить. Просто уберите из разметки все атрибуты высоты и ширины (например, удалите width="640" height="480") и добавьте в CSS следующий код:
video { max-width: 100%; height: auto; }
Но, вполне успешно работая с файлами, которые могут храниться на локальном устройстве, этот прием не решает проблемы видео, встроенного в iFrame (низкий поклон YouTube, Vimeo и другим сайтам). Следующий код позволяет добавить трейлер фильма «Успеть до полуночи» из YouTube:
<iframe width="960" height="720" src="/
watch?v=B1_N28DA3gY" frameborder="0" allowfullscreen></iframe>
Но если добавлять этот код к странице в неизменном виде, то даже при добавлении предшествующего CSS-правила, если ширина окна просмотра будет менее 960 пикселов, произойдет обрезка.
Проще всего решить эту проблему с помощью небольшого CSS-трюка, впервые примененного французским CSS-специалистом Тьерри Кобленцем (Thierry Koblentz), который создал, по сути, блок с правильным соотношением сторон для содержащегося в нем видео. Я не стану пересказывать собственные объяснения этого мага, которые можно найти по адресу .
Если лень, вам даже не нужно самим вычислять и подставлять соотношение сторон, поскольку существует онлайн-сервис, способный сделать это за вас. Просто обратитесь по адресу / и поместите в адресную строку этого сайта URL-адрес вашего iFrame. Сайт выдаст вам простой фрагмент кода, который можно вставить в свою страницу. К примеру, для трейлера фильма «Успеть до полуночи» будет получен следующий результат:
<style>.embed-container { position: relative; padding-bottom: 56.25%;
height: 0; overflow: hidden; max-width: 100%; height: auto; } .embed-
container iframe, .embed-container object, .embed-container embed {
position: absolute; top: 0; left: 0; width: 100%; height: 100%; }</
style><div class='embed-container'><iframe src='.
com/embed/B1_N28DA3gY' frameborder='0' allowfullscreen></iframe></div>
Вот и все, просто добавьте этот фрагмент к своей странице и получите полностью адаптируемое YouTube-видео (примечание: дети, не берите пример с мистера Де Ниро, курить вредно!).
Я уверен, что идеальный способ создания адаптивных веб-страниц и веб-приложений основан на приоритетности автономной работы. Этот подход означает, что сайты и приложения будут продолжать работать и загружаться даже без интернет-соединения. Для достижения этой цели предназначены автономные веб-приложения на HTML5 ().
Хотя такие приложения имеют довольно широкую поддержку (), к сожалению, этому решению еще далеко до идеала. При всей относительной простоте его настройки существует целый ряд ограничений и подводных камней. Описание всех препятствий не входит в задачи данной книги. Поэтому я рекомендую прочитать написанную с юмором и довольно подробную статью на эту тему Джейка Арчибальда (Jake Archibald), которую можно найти по адресу .
Я же по этому поводу придерживаюсь мнения, что, несмотря на возможность получения положительного опыта приоритетности автономной работы с помощью автономных веб-приложений (неплохое руководство по способам достижения этой цели можно найти по адресу ) и LocalStorage (или какой-нибудь комбинации этих двух средств), до наилучшего решения нам еще слишком далеко. Я возлагаю свои надежды на Service Workers (/).
На момент написания данной книги Service Workers все еще пребывала в статусе относительно новой спецификации, но в качестве неплохого обзора, я предлагаю посмотреть следующее 15-минутное введение: . Прочитайте еще это введение: / — и проверьте возможность поддержки на сайте /.
Надеюсь, к тому времени, когда я займусь подготовкой третьего издания этой книги (если, конечно, возьмусь за него), появится возможность дать полный обзор и описание реализации этой технологии. Скрестим пальцы на удачу.
В данной главе был рассмотрен довольно объемный материал. Все, начиная с основ создания страницы, проходящей проверку на соответствие стандартам HTML5, и заканчивая встраиваемым в вашу разметку сложным медиасодержимым (видео) и вопросами обеспечения его адаптивного поведения.
Хотя это и не имеет отношения к адаптивному дизайну, мы разобрались также в способах написания семантически обогащенного и осмысленного кода и рассмотрели вопрос смыслового наполнения страниц и обеспечения их пригодности для тех пользователей, которые зависят от применения вспомогательных технологий.
Текущая глава была слишком перегружена разметкой, поэтому теперь поменяем задачу. В следующих двух главах мы собираемся постичь всю мощь и гибкость CSS. Сначала рассмотрим эффективность применения селекторов CSS уровня 3 и 4, новые единицы измерения CSS, относящиеся к окнам просмотра, и такие возможности, как использование функции calc и HSL-цвета. Все это позволит нам создавать более быстрые, имеющие более впечатляющие возможности и легче сопровождаемые адаптивные конструкции.