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

В HTML5 нет исключенных элементов или атрибутов. Но зато есть огромное количество устаревших элементов и атрибутов.

Нет, это не очередной случай выжившей из ума политкорректности. «Устаревший» имеет несколько иное значение, чем «исключенный».

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

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

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

Устаревшими стали элементы frame, frameset и noframes.

Никто не будет по ним скучать.

Устарел элемент acronym, освободив таким образом годы времени на споры, которые можно использовать с бо́льшим толком: хотя бы рассчитать наконец теоретически возможную плотность одновременного количества ангелов на булавочной головке стандартного размера[2]. Не плачьте по элементу acronym – используйте вместо него элемент abbr. Да, я знаю, что между акронимами и аббревиатурами есть разница: акронимы произносятся как одно целое слово (например: НАТО, ЮНЕСКО), но просто запомните: все акронимы – аббревиатуры, но не все аббревиатуры – акронимы.

Элементы, относящиеся исключительно к представлению, такие как font, big, center и strike, также являются устаревшими в HTML5. В действительности они являются устаревшими уже несколько лет: гораздо проще добиться того же самого эффекта в оформлении с помощью CSS-свойств: например, font-size и text-align. Точно также атрибуты, относящиеся к представлению: bgcolor, cellspacing, cellpadding и valign, являются устаревшими. Просто используйте CSS.

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

Элемент big является устаревшим, а вот элемент small – нет. Чтобы это не выглядело непоследовательным, было решено переопределить, что значит в данном случае «маленький». Раньше мы понимали «маленький» как термин, связанный только с представлением: «это нужно отображать шрифтом маленького размера». Вместо этого появилось семантическое значение: «это то, что набирается мелким шрифтом», то есть текст для юридических нюансов или условий использования.

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

Элемент b раньше означал: «это нужно отобразить полужирным шрифтом». Теперь его можно использовать, чтобы текст «стилистически отличался от обычного текста, не передавая при этом семантики дополнительной важности». Если этот фрагмент текста более важен, чем окружающий текст, тогда больше подойдет элемент strong.

Точно также элемент i не значит больше «отобразить текст курсивом». Теперь этим элементом описывается текст, «произнесенный другим голосом или с другим настроением». Опять же, этот элемент не предполагает дополнительной важности или акцента на текст. Если вы хотите, чтобы акцент был, используйте элемент em.

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

В HTML5 изменено определение элемента cite. Раньше он означал «отсылку к другим источникам», а теперь – «название работы, к которой идет отсылка». Достаточно часто ссылка на источник цитаты и есть название работы (скажем, книги или фильма), но настолько же часто источником может быть и человек. До HTML5 вы могли разметить имя этого человека с помощью cite. Теперь это однозначно запрещено – прощай, обратная совместимость.

Оправдывают это изменение примерно следующим: браузеры выделяют текст внутри тега <cite> курсивом; названия работ обычно выделяют курсивом[3], а имена людей – нет, таким образом, элемент cite не должен использоваться для того, чтобы размечать имена авторов.

Это просто неправильно. Я полностью за то, чтобы HTML5 ориентировалась на существующие в браузерах реалии, но здесь явный случай того, когда хвост виляет собакой.

К счастью, ни один валидатор не отличит, относится ли текст между открывающими и закрывающими тегами <cite> к человеку или нет, так что ничто не мешает нам, веб-разработчикам, использовать элемент cite имеющим смысл образом, к тому же поддерживающим обратную совместимость.

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

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

Элемент a всегда был строчным (inline) элементом. Если вы хотели сделать заголовок и абзац гиперссылками, нужно было использовать несколько элементов a:

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

Элемент canvas – среда для создания динамических картинок.

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

<canvas id="my-first-canvas" width="360" height="240">

</canvas>

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

<canvas id="my-first-canvas" width="360" height="240">

<p>Браузер не поддерживает canvas? Тогда картинка,по-старинке:</p>

<img src="puppy.jpg" alt="очаровательный щенок">

</canvas>

Браузер не поддерживает canvas? Тогда картинка по старинке:

^{Рис. 3.01. Пользователи, браузеры которых не поддерживают canvas, увидят картинку очаровательного щенка}

Вся сложная работа делается на JavaScript. Сначала вам нужно будет создать переменную, указывающую на Canvas и его контекст. Слово «контекст» в данном случае означает просто API. В настоящий момент контекст есть только один – двумерный:

var canvas = document.getElementById(‘my-first-canvas’);

var context = canvas.getContext(‘2d’);

Теперь вы можете начать рисовать на двумерной поверхности элемента canvas, используя API, задокументированное в спецификации HTML5 по адресу: http://bkaprt.com/html5/.[4]

В 2D API есть довольно большое количество тех же самых инструментов, которые есть в графическом редакторе (например, Adobe Illustrator), – обводка, заливка, градиент, тень, формы, кривые Безье. Разница в том, что вместо того чтобы использовать графический интерфейс, вам нужно писать все на JavaScript.

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

context.strokeStyle = ‘#990000’;

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

strokeRect (left, top, width, height)

Если вы хотите нарисовать прямоугольник размерами 100×50 пикселей, расположенный в 20 пикселях от левого края и в 30 пикселях от верхнего края элемента canvas, вы напишете так (рис. 3.02):

context.strokeRect(20,30,100,50);

Это очень простой пример. 2D API предоставляет очень много методов: fillStyle, fillRect, lineWidth, shadowColor и многие другие.

^{Рис. 3.02. Прямоугольник, нарисованный на canvas}

В теории любое изображение, которое можно реализовать в программе, аналогичной Illustrator, можно создать внутри элемента canvas. На практике делать это очень утомительно и, скорее всего, приведет к безумно длинному коду на JavaScript. Да и вообще смысл Canvas несколько не в этом.

Создавать картинки на лету с использованием JavaScript и Canvas – это все здорово и прекрасно, но если вы не убежденный мазохист, то зачем?

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

Одна из первых флагманских демонстраций возможностей Canvas была разработана в Mozilla Labs. Приложение Bespin (https://bespin.mozilla.com) – редактор кода, работающий внутри браузера (рис. 3.03).

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

^{Рис. 3.03. Приложение Bespin, разработанное на Canvas}

Редактор кода по своей природе имеет дело с текстом. Редактор Bespin работает с текстом внутри элемента canvas – вот только на самом деле это уже не текст; это набор фигур, которые выглядят как текст.

Каждый документ в вебе можно описать объектной моделью документа (Document Object Model, DOM). DOM может содержать большое количество различных узлов, самыми важными из которых являются узлы элементов, текстовые узлы и атрибуты. У элемента canvas нет DOM. Содержимое, нарисованное внутри canvas, нельзя представить как дерево узлов.

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

Недоступность содержимого Canvas для технологий специальных возможностей – большая проблема для HTML5. К счастью, очень умные люди работают вместе в рамках рабочей группы, которая может предложить решение этой проблемы (http://bkaprt.com/html5/2)[5].

Доступ к Canvas – очень важный вопрос, и я не хотел бы, чтобы какие-либо внесенные предложения принимались поспешно. С другой стороны, мне не хотелось бы также, чтобы Canvas задерживал все остальное в спецификации HTML5.

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

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

Этот многоуровневый подход, называющийся еще «ненавязчивый JavaScript», можно применить и к Canvas. Вместо того чтобы использовать Canvas для создания содержимого, используйте его, чтобы иначе отобразить существующее содержимое.

Предположим, у вас есть таблица с данными. Скажем, вы хотите проиллюстрировать аналитические выводы из этих данных в диаграмме. Если данные статичны, то вы можете сгенерировать картинку диаграммы – например, используя Google Chart API. Если же данные редактируемы, если они меняются в ответ на события, вызванные действиями пользователя, тогда Canvas – отличный инструмент для того, чтобы сгенерировать изменившуюся диаграмму. Ключевой момент здесь тот, что то содержимое, которое выводится внутри элемента canvas, уже доступно в существующем элементе table.

Умные парни из Filament Group разработали jQuery-плагин как раз для такой ситуации (рис. 3.04; http://bkaprt.com/html5/3)[6].

^{Рис. 3.04. Сгенерированная с помощью Canvas диаграмма из данных, введенных пользователями}

Есть и другой вариант. Canvas – не единственная API для генерации динамических картинок. SVG (Scalable Vector Graphics, масштабируемая векторная графика) – XML-формат, в котором можно описать те же самые формы, что и в Canvas.

Поскольку XML – текстовый формат данных, содержимое SVG теоретически доступно программам, читающим текст на экране.

На практике SVG не захватило воображение разработчиков настолько, насколько это получилось у Canvas. Хотя Canvas – новый паренек в классе, у него уже отличная браузерная поддержка. Safari, Firefox, Opera и Chrome поддерживают Canvas. Есть даже JavaScript-библиотека, которая добавляет поддержку Canvas в Internet Explorer (http://bkaprt.com/html5/4)[7].

Учитывая мантры WHATWG – «асфальтируйте тропинки» и «не изобретайте велосипед», – может показаться странным, что при этом они выступают за включение Canvas в HTML5, когда уже существует стандарт SVG. Как часто и бывает, спецификация HTML5 только документирует то, что браузеры уже поддерживают. Элемент canvas не был задуман специально для HTML5; он был разработан Apple и реализован в Safari. Другие производители браузеров увидели, что делает Apple, им это понравилось, они это скопировали.

Звучит как-то несуразно, но зачастую именно так рождаются наши веб-стандарты. Например, в конце XX века Microsoft создала объект XMLHttpRequest для Internet Explorer 5.

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

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

Первым сайтом, который я сделал в жизни, был маленький сайт-визитка моей группы. Я хотел, чтобы посетители сайта могли слушать песни, которые исполняет моя группа. Так начался мой спуск в подземное царство огромного количества форматов и музыкальных проигрывателей. Многие из них боролись за мое внимание: QuickTime, Windows Media Player, Real Audio, – и я потратил слишком много времени, переживая из-за доли каждого на рынке и кросс-платформенной совместимости.

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

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

Встроить аудиофайл в HTML5-документ очень просто:

Элемент audio можно использовать не только для злых, но и для благих целей. Дать пользователю контроль над управлением проигрывания аудиофайла – здравая идея, которую легко осуществить с помощью булева атрибута controls:

<audio src="witchitalineman.mp3" controls>

</audio>

Присутствие атрибута controls заставляет браузер отобразить встроенные элементы управления того, чтобы проигрывать аудиофайл и ставить его на паузу – и для того, чтобы настраивать громкость (рис. 3.05).

^{Рис. 3.05. Используйте атрибут controls, для того чтобы отобразить элементы управления «проиграть», «пауза» и управления громкостью}

Если вам не нравятся встроенные в браузер элементы управления, можете создать свои собственные. С помощью JavaScript вы можете взаимодействовать с Audio API, которое дает вам доступ к методам (play и pause) и свойствам (volume и др.). Вот быстрый и простой пример, как использовать элементы button и ужасные обработчики событий, написанные прямо в коде страницы (рис. 3.06):

<audio id="player" src="witchitalineman.mp3">

</audio>

<div>

<buttononclick="document.getElementById(‘player’). play()">Проиграть

</button>

<buttononclick="document.getElementById(‘player’). pause()">Пауза

</button>

<buttononclick="document.getElementById(‘player’). volume+= 0.1">

Громче

</button>

<buttononclick="document.getElementById(‘player’). volume-= 0.1">

Тише

</button>

</div>

^{Рис. 3.06. Элементы управления (Проиграть, Пауза, Громче, Тише), сделанные с помощью элементов button}

В какой-то момент спецификация HTML5 включала еще один булев атрибут для элемента audio. Атрибут autobuffer был более вежливым и продуманным вариантом неприятного атрибута autoplay. Он позволял авторам сообщить браузеру, что хотя аудиофайл и не нужно начинать проигрывать автоматически, скорее всего в какой-то момент пользователь начнет его проигрывать, поэтому браузеру стоит начать подгружать файл в фоновом режиме.

Это был бы полезный атрибут, но, к сожалению, Safari сделал лишний шаг вперед. Этот браузер начал подгружать аудиофайлы вне зависимости от того, присутствует атрибут autobuffer или нет. Не забывайте, что из-за того, что autobuffer – булева переменная, не было никакого способа сказать Safari, что подгружать аудиофайл не нужно: autobuffer="false" – то же самое, что autobuffer="true" или любое другое значение (http://bkaprt.com/html5/5)[9].

В данный момент атрибут autobuffer заменен атрибутом preload. Это не булев атрибут. Он принимает одно из трех возможных значений: none, auto и metadata. Написав preload="none", вы можете явным образом указать браузеру, что подгружать аудиофайл заранее не нужно:

Элемент audio выглядит практически идеальным. Где-то должен быть подвох, правда? Он есть.

Проблемы с элементом audio не в спецификации. Главная проблема – с форматами аудиофайлов.

Хотя формат MP3 и распространен повсеместно, это не открытый формат. Из-за того, что на этот формат навешано множество патентов, нельзя написать декодер MP3, не заплатив отчислений по патенту. У корпораций вроде Apple или Adobe с этим нет проблем, но для маленьких компаний или опенсорс-групп это не так просто. Поэтому Safari будет с удовольствием проигрывать MP3-файлы, a Firefox – нет.

На свете есть и другие аудиоформаты. Кодек Vorbis – обычно для него используется файл с расширением .ogg – никакими патентами не обременен. Firefox поддерживает Ogg Vorbis, а Safari – нет.

К счастью, есть способ использовать элемент audio, не делая при этом «выбор Софи»[10] между форматами файлов. Вместо того чтобы использовать атрибут src в открывающем теге <audio>, можно указать несколько форматов файлов с помощью элемента source:

Возможность указывать несколько элементов source очень удобна. Но есть браузеры, которые пока не поддерживают элемент audio совсем. Угадаете, на который браузер я намекаю?

Internet Explorer и его родню нужно кормить аудиофайлами с ложечки, по старинке, через Flash. Модель содержимого элемента audio позволяет это сделать. Все, что находится между открывающим и закрывающим тегами <audio> – и что при этом не является элементом source – будет показываться браузерам, которые не понимают элемента audio:

Модель содержимого элемента audio очень удобна для предоставления «запасного варианта» содержимого. Запасное содержимое – не то же самое, что содержимое для технологий специальных возможностей.

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

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

Элемент video работает примерно так же, как элемент audio. У него есть необязательные атрибуты autoplay, loop и preload. Вы можете указать расположение видеофайла либо через атрибут src элемента video, либо с помощью элементов source, вложенных внутри открывающих и закрывающих тегов <video>. Вы можете разрешить браузеру отобразить пользовательский интерфейс с помощью атрибута controls или написать свои собственные управляющие элементы.

Главная разница между аудио– и видеосодержимым состоит в том, что фильмы по своей природе будут занимать больше места на экране, поэтому, скорее всего, вам стоит определить размеры элемента:

<video src="movie.mp4" controls width="360" height="240">

</video>

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

<video src="movie.mp4" controls width="360"height="240" poster="placeholder.jpg">

</video>

^{Рис. 3.07. Через атрибут poster показывается картинка-заполнитель}

Поле битвы конкурирующих видеоформатов «залито кровью» еще сильнее, чем в мире аудио. Из больших игроков нужно назвать MP4 – по уши увязшего в патентах – и Theora Video (здесь все проще). И снова вам нужно будет указать альтернативные форматы и содержимое, которое выводится в том случае, если HTML5 video не поддерживается:

<video controls width="360" height="240"poster="placeholder.jpg">

<source src="movie.ogv" type="video/ogg">

<source src="movie.mp4" type="video/mp4">

<object type="application/x-shockwave-flash"width="360" height="240"data="player.swf?file=movie.mp4">

<param name="movie"value="player.swf?file=movie.mp4">

<a href="movie.mp4">Скачать фильм</a>

</object>

</video>

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

Возможность нативного встраивания видео в веб-страницы – пожалуй, самое заманчивое добавление к HTML со времен введения элемента img. Большие игроки, как, например Google, не стесняются выражать свой энтузиазм на этот счет. Вы можете взглянуть на то, что они приготовили для YouTube, по адресу: http://youtube.com/html5.

Одной из проблем отображения мультимедиа в плагине является то, что содержимое плагина находится в «песочнице», отдельно от всего остального документа. Нативные мультимедиа-элементы в HTML смогут работать в комплексе с остальными браузерными технологиями – JavaScript и CSS. Элементом video можно не только управлять через JavaScript, можно также назначать ему стили (рис. 3.08).

^{Рис. 3.08. Элемент video с примененными стилями}

Попробуйте-ка сделать это с плагином.

Аудио и видео – долгожданные дополнения к HTML5, но веб – не среда вещания, а интерактивная среда. Самый старый и самый мощный способ обеспечивать интерактивность – формы. В главе 4 мы посмотрим на то, какое обновление в HTML5 получили формы.

В HTML5 стало намного больше вариантов атрибута type элемента input. Здесь нужно заасфальтировать столько тропок, что это похоже на строительные работы после того, как по лесу в панике пробежала толпа дачников.

Элемент input со значением “search” в атрибуте type будет вести себя примерно так же, как элемент ввода со значением “text” атрибута type:

<label for="query">Поиск</label>

<input id="query" name="query" type="search">

Единственная разница между “text” и “search” состоит в том, что браузер может отображать поле для поиска иначе для того, чтобы соответствовать стилю полей поиска в операционной системе. Именно так делает Safari (рис. 4.04).

^{Рис. 4.04. Safari устанавливает стили полей поиска в соответствии с Mac OS}

В HTML5 добавилось три новых типа type для особенных типов контактов: e-mail-адресов, веб-сайтов и номеров телефонов:

<label for="email">Email-адрес</label>

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

<label for="website">Вебсайт</label>

<input id="website" name="website" type="url">

<label for="phone">Телефон</label>

<input id="phone" name="phone" type="tel">

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

Разработчики Safari уверяют, что их браузер поддерживает эти новые типы ввода, но при быстром взгляде на форму в десктоп-браузере не видно никаких различий с простым использованием type="text". Однако, если вы начнете работать с этой же формой в Mobile Safari, различия станут очевидными. Браузер показывает разные экранные клавиатуры в зависимости от значения атрибута type (рис. 4.05).

Тонко сделано, Webkit, тонко.

^{Рис. 4.05. Mobile Safari показывает разные экранные клавиатуры в зависимости от значения атрибута type}

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

Классический пример – ползунок. До сих пор нам приходилось использовать JavaScript для того, чтобы эмулировать этот в каком-то смысле интерактивный элемент. В HTML5 благодаря type="range" можно воспользоваться элементом управления, встроенным в браузер:

<label for="amount">Почем опиум для народа?</label>

<input id="amount" name="amount" type="range">

Safari и Opera на данный момент поддерживают этот тип элемента ввода, предлагая похожие элементы управления (рис. 4.06).

^{Рис. 4.06. Тип ввода range в Safari и Opera}

По умолчанию элемент ввода принимает значения от нуля до ста. Вы можете поставить свои собственные минимальные и максимальные значения с помощью атрибутов min и max:

<label for="rating">Ваша оценка</label>

<input id="rating" name="rating" type="range" min="1" max="5">

Для пользователей Safari и Opera все здорово и прекрасно; другие браузеры просто будут выводить обычное текстовое поле. Это, наверное, нормально, но вы, пожалуй, захотите использовать запасное решение на JavaScript для браузеров, которые не поддерживают type="range".

Для того чтобы проверить, есть ли в браузере встроенная поддержка типов ввода, нужен прием, похожий на проверку на поддержку атрибута. Опять же вам нужно будет создать в памяти «фантомный» элемент input. Затем вы устанавливаете атрибут type на то значение, которое хотите проверить.

После этого вы запрашиваете значение свойства type, и если получаете значение “text”, то вы знаете, что браузер не поддерживает то значение, которое вы установили.

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

Встроенный в браузер элемент управления range не показывает пользователю свое внутреннее значение. Вместо этого номер переводится в графическое представление ползунка. Это отлично для определенных типов данных. Другие типы данных предназначены для того, чтобы пользователь мог видеть и выбирать числовое значение. Здесь на помощь приходит type="number":

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

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

HTML5 вводит целую уйму типов полей ввода специально для даты и времени:

• date предназначен для года, месяца и дня.

• datetime предназначен для года, месяца и дня вместе с часами, минутами, секундами и информацией о временной зоне.

• datetime-local – то же самое, но без информации о временной зоне.

• time – только часы, минуты и секунды.

• month – год и месяц, но без дня.

Все эти типы ввода будут записывать временные величины в какой-либо части стандартного формата YYYY-MM-DDThh: mm: ss.Z (Y – год, M – месяц, D – день, h – час, m – минута, s – секунда, а Z – временная зона). Возьмем, например, дату и время, когда закончилась Первая мировая война, в 11:11 11 ноября 1918 года:

• date: 1918-11-11

• datetime: 1918-11-11T11:11:00+01

• datetime-local: 1918-11-11T11:11:00

• time: 11:11:00

• month: 1918-11

Типа ввода year нет, хотя существует тип ввода week, который принимает число от 1 до 53 вместе с годом.

Использовать типы ввода даты и времени достаточно просто:

<label for="dtstart">Дата начала</label>

<input id="dtstart" name="dtstart" type="date">

Opera реализует эти типы ввода с помощью своей запатентованной технологии, заставляющей все выглядеть безобразно (рис. 4.08).

^{Рис. 4.08. Встроенное в Opera отображение календаря – совершенно безобразное}

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

if (!inputSupportsType('date')) {

// Сгенерировать виджет календаря.

}

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

Пожалуй, самый амбициозный элемент в HTML5, заменяющий JavaScript-виджет, – тип ввода color. Он принимает значение в знакомом шестнадцатеричном формате: #000000 – черный, #FFFFFF – белый.

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

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

Другие языки разметки позволяют вам изобретать любой элемент, какой пожелаете. В XML, если вы хотите, чтобы в вашем документе был элемент event или price, вы просто берете и создаете его. Недостаток этой свободы заключается в том, что вам нужно будет затем обучить парсер, что значит event и price. Достоинство ограниченного набора элементов HTML в том, что каждая программа, работающая с ним, знает о существовании каждого из этих элементов. В браузеры встроено знание HTML. Это было бы невозможно, если бы нам разрешалось придумывать названия элементов.

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

Если в этом месте вы думаете: «Погодите-ка, разве классы нужны не для CSS?», вы отчасти правы. CSS-селекторы по классам – один из примеров технологии, которая использует атрибут class, но это не единственная причина использовать классы. Классы могут использоваться при написании скриптов для DOM и даже могут использоваться браузерами, если названия классов следуют заранее согласованным правилам, как это происходит в случае микроформатов.

Микроформаты – набор договоренностей, согласованных внутри сообщества. Эти форматы используют атрибут class для того, чтобы заделать самые зияющие дыры в HTML: hCard – для контактов, hCalendar – для событий, hAtom – для новостных репортажей. Поскольку внутри сообщества существует договоренность о том, какие имена классов следует использовать, существуют парсеры и расширения браузеров, которые работают именно с этими шаблонами.

Микроформаты ограничены по самой своей задумке. Они не пытаются предложить решение для любого возможного сценария использования. Напротив, они нацеливаются на тот плод, что низко висит. Они предлагают решения для 80% сценариев использования, при этом на их создание затрачивается всего 20% усилий. Решить, что считается «плодом, что низко висит», довольно просто: нужно просто посмотреть на содержимое, которое люди уже размечают. Другими словами, заасфальтировать тропинки.

Звучит знакомо? Микроформаты и HTML5 построены на одной философии. По сути, то, как я описал микроформаты – договоренности, согласованные сообществом, – вполне применимо и к HTML5.

То, что микроформаты использовались в качестве модели для разработки HTML5, приходится не всем по вкусу. Хотя правило 80/20 достаточно хорошо работает для сермяжного мира наименований классов, действительно ли оно достаточно хорошо для самого важного языка разметки в мире?

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

Пожалуй, самый красноречивый аргумент такого типа привел Джон Олсоп (John Allsopp) в своей великолепной статье на A List Apart, «Семантика в HTML5» (http://bkaprt.com/html5/6)[11]:

Уже существуют технологии для того, чтобы делать именно это. RDFa позволяют авторам встраивать в HTML-документы собственные словари. Но в отличие от микроформатов – которые просто используют заранее оговоренный набор наименований классов, – RDFa использует пространства имен для бесконечного разнообразия форматов. Так, там, где микроформат будет использовать примерно такую разметку: <h1 class="summary">, RDFa будет использовать: <h1 property="myformat:summary">.

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

Спор о пространствах имен не нов. В записи в своем блоге несколько лет назад Марк Ноттингем (Mark Nottingham) размышлял о потенциально деструктивных побочных эффектах (http://bkaprt.com/html5/7)[12]:

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

Скорее всего, HTML5 будет выпущен с каким-либо методом расширения его встроенной семантики. Конечно, атрибут class все еще на месте, поэтому микроформаты будут работать так, как работали. Возможно, HTML5 изменится, чтобы стать совместимым с RDFa, или, возможно, он будет использовать свой собственный словарь «микроданных».

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

HTML5 вводит несколько новых строчных элементов, чтобы расширить наш существующий арсенал, состоящий из span, strong, em, abbr и других. Ах да, больше мы не называем такие элементы «строчными» – теперь они описывают «семантику на уровне текста».

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

Можно использовать em или strong, но это не будет семантически верным; вы не хотите придавать особую важность запросу поиска, просто хотите, чтобы он был как-то выделен.

На сцену выходит элемент mark:

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

Единственная сложная часть в hCalendar – описывать дату и время так, чтобы компьютер мог их прочитать. Люди любят описывать даты: «25 мая» или: «в следующую среду», но парсеры хотят видеть красиво отформатированную по ISO дату: YYYY-MM-DDThh: mm: ss.

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

Элемент meter может использоваться для разметки любых измерений, если эти измерения являются частью шкалы с минимальным и максимальным значением.

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

Еще в 2005 году компания Google провела ряд исследований, чтобы обнаружить, какие именно низко висящие плоды можно найти на тропках веба (http://code.google.com/webstats/).

Парсер осмотрел более миллиарда веб-страниц и разметил самые частые названия классов. Результаты не принесли ничего неожиданного. Наиболее частыми были такие названия классов, как “header”, “footer” и “nav”. Эта зарождавшаяся в то время семантика отлично соотносится с новыми структурными элементами, появившимися в HTML5.

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

Вы вполне можете заменить ряд элементов div в своем коде элементами section, но не забудьте спросить себя: «Все ли содержимое связано друг с другом?»

Спецификация HTML5 описывает элемент header как контейнер для «группы вводных или навигационных вспомогательных элементов». Звучит вполне разумно. Это как раз тот тип содержимого, который я ожидаю увидеть в шапке страницы, и слово header как раз традиционно используется как синоним термина «шапка».

Между элементом header в HTML5 и общепринятым использованием слов header и «шапка» есть принципиальная разница. На странице шапка обычно только одна, но в документе может быть много элементов header. Вы можете, например, использовать элемент header внутри элемента section. Пожалуй, это даже нужно делать. Спецификация определяет элемент section как «контейнер тематически сгруппированного содержимого, как правило, с заголовком».

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

Это отлично согласовывается с той ментальной моделью, которая есть у веб-разработчиков для слова «подвал». Разница в том, что, хотя мы привыкли использовать один подвал на весь документ, HTML5 позволяет нам делать подвалы и внутри секций.

<section>

<header>

<h1>Скрипты для DOM</h1>

</header>

<p>Эта книга скорее предназначена для дизайнеров, чем для программистов.</p>

<footer>

<p>автор: Джереми Кит</p>

</footer>

</section>

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

Элемент aside должен использоваться для не связанного напрямую содержимого. Если у вас есть блок содержимого, который вы считаете отдельным от основного содержимого, тогда, возможно, его следует заключить в элемент aside. Задайте себе вопрос: можно ли удалить содержимое элемента aside так, что при этом главное содержимое документа или секции не потеряет смысл?

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

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

^{Рис. 5.01. Текст «об авторе» в этом скриншоте должен быть размечен с помощью footer, а не aside}

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

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

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

Довольно часто элемент nav появляется внутри элемента header. Это вполне осмысленно, если вы вспомните, что элемент header может использоваться для «вспомогательной навигационной информации».

Для лучшего понимания можно представить, что элементы header, footer, nav и aside – это специализированные формы элемента section. Секция – это общий блок связанного содержимого, а шапки, подвалы, навигационные блоки и боковые колонки – блоки особого связанного содержимого.

Элемент article – еще один особый вид section. Его следует использовать для самостоятельного связанного содержимого. Теперь сложная часть – это решить, что значит «самостоятельный».

Задайте себе вопрос, стали бы вы передавать это содержимое в RSS или Atom-ленте. Если в таком конктексте это содержимое имеет смысл, тогда, скорее всего, article – нужный вам элемент. На самом деле элемент article спроектирован специально для агрегирования.

Если внутри article вы используете элемент time, можете добавить к нему необязательный булев атрибут pubdate, чтобы указать, что он содержит дату публикации:

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

^{Рис. 5.02. Блог вашего покорного слуги}

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

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

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

Строчные элементы теперь имеют модель содержимого «семантики на уровне текста». Многие блочные элементы теперь подпадают под категорию «группирующего содержимого»: абзацы, списки, дивы и т. п. У форм есть своя собственная модель содержимого. Картинки, звук, видео и Canvas относятся к встроенному содержимому. У новых структурных элементов появляется совершенно новая модель содержимого, которая называется «содержимое-разделитель».

Используя элементы заголовков, от h1 дo h6, можно создать содержание HTML-документа. Например, посмотрите вот на эту разметку:

Пока новое содержимое-разделитель не дает нам ничего такого, чего мы не могли бы делать с предыдущими версиями HTML. Вот самое интересное: в HTML5 у каждого содержимого-разделителя есть свое собственное внутреннее содержание. Таким образом, вам не нужно следить, на каком уровне заголовков вы находитесь, – можете просто каждый раз начинать с h1:

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

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

Элементы blockquote, fieldset и td являются исключениями для алгоритма составления содержания. Эти элементы называются «корневыми элементами разделов» – это не нужно путать с элементами-разделителями.

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

Предположим, у меня есть запись в блоге под названием «Бутерброд с сыром». До HTML5 мне нужно было бы знать контекст, в котором расположена запись, чтобы определить, какой уровень заголовков использовать для заголовка записи. Если запись находится на главной странице, то она появляется вслед за элементом h1, который содержит название моего блога:

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

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

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

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

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

Джоффри Снеддон (Geoffrey Sneddon) написал очень полезную онлайн-утилиту, которая сгенерирует содержание по спецификациям HTML5 (http://bkaprt.com/html5/9)[14].

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

Только вы решаете, как будете использовать HTML5 – осторожно или, наоборот, амбициозно.

По крайней мере что вы можете сделать без всяких проблем – это взять ваши текущие HTML– или XHTML-документы и изменить доктайп на:

Я довольно часто пишу о HTML5 на своей личной страничке: http://adactio.com/journal/tag/html5

Я не единственный человек в мире, который с нетерпением ждет HTML5. Невероятный Брюс Лосон (Bruce Lawson) тоже записывает свои мысли: http://brucelawson.co.uk/category/html5/

Брюс – только один из активных участников HTML5 Doctor – отличного ресурса, сообщество которого пишет здесь множество прекрасных статей: http://html5doctor.com/

Если вы раздумываете, не взглянуть ли на более сложную сторону HTML5, то Реми Шарп выжимает из этого языка разметки все, что возможно: http://html5demos.com/

Марк Пилгрим (Mark Pilgrim) написал исчерпывающую книгу под названием «Погружение в HTML5» (Dive Into HTML5). Вы можете купить ее на сайте издательства O’Reilly или прочитать онлайн: http://diveintohtml5.org/

На тот случай, когда вам нужно отправиться напрямую к исходной точке, держите спецификацию HTML5 на кнопке быстрой загрузки: http://whatwg.org/html5

Спецификация HTML5 включает в себя большое количество информации, предназначенной для производителей браузеров. На сайте W3C есть актуальная версия спецификации специально для веб-разработчиков: http://www.w3.org/TR/html-markup