Было приятно познакомиться, чао

Устаревшими стали элементы 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 имеющим смысл образом, к тому же поддерживающим обратную совместимость.

Элемент a на стероидах

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

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

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

<p><a href="/about">Узнайте, почему я такой.</a></p>

В HTML5 вы можете обернуть несколько элементов в один элемент a:

<p>Узнайте, почему я такой.</p>

</a>

Единственная оговорка – вы не можете поместить элемент a внутри другого элемента a.

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

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

Новые игрушки! API JavaScript

Если вы хотите почитать документацию по CSS, то отправляетесь смотреть спецификацию CSS. Если ищете документацию по разметке, обращаетесь к спецификации HTML. Но где можно найти спецификацию по различным API JavaScript, таким как document.write, innerHTML и window.history? Спецификация JavaScript касается только языка программирования – вы не найдете в ней никаких браузерных API.

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

Кажется странным, что документация по JavaScript находится в спецификации разметки, но не забывайте, что HTML5 начал свое существование как спецификация для веб-приложений (Web Apps 1.0). JavaScript – неотъемлемая часть разработки веб-приложений.

Ряд разделов спецификации HTML5 целиком посвящен новым API для создания веб-приложений. Описан, например, менеджер отмены (UndoManager), который позволяет браузеру отслеживать изменения документа. Есть отдельный раздел по созданию офлайновых веб-приложений с помощью использования манифеста кэширования. Детально описан процесс перетаскивания объектов.

Как всегда, если уже существует реализация, спецификация будет опираться на нее, а не изобретать велосипед. В Internet Explorer уже несколько лет существует API для перетаскивания объектов, поэтому она и стала фундаментом для перетаскивания в HTML5. К сожалению, у API Microsoft – как бы помягче сказать – есть свои проблемы. Может быть, иногда не так уж плохо заново изобретать велосипед, если у тебя есть только велосипед с квадратными колесами.

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

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

Мультимедиа

История веба пестрит технологическими нововведениями. Одним из самых ранних добавлений к HTML стал элемент img, и это фундаментально изменило веб. Затем появление JavaScript позволило вебу стать более динамической средой. Наконец, быстрый рост количества Ajax-приложений позволил вебу стать средой, в которой возможны полноценные приложения.

Веб-стандарты продвинулись настолько, что сейчас возможно разработать практически все что угодно с помощью HTML, CSS и JavaScript.

В разнообразном наборе веб-стандартов есть пробелы. Если вы хотите опубликовать текст и картинки, вам ничего не нужно, кроме HTML и CSS. Но если вы хотите опубликовать аудио и видео, вам понадобится технология, существующая в виде плагинов, – например, Flash или Silverlight.

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

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

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

Canvas

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

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

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

</canvas>

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

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

</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 несколько не в этом.

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

Пока проблема с доступом технологий специальных возможностей не решена, может показаться, что 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 распространяется вширь и вдаль. Если он сможет приспособиться к технологиям специальных возможностей, выживание ему обеспечено.

Audio

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

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

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

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

</audio>

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

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

</audio>

Если вы когда-нибудь будете так использовать атрибут autoplay, знайте: я вас найду.

Обратите внимание, что у атрибута autoplay нет значения. Такие атрибуты называются булевыми, в честь Джорджа Буля, великого математика из Корка[8].

Компьютерная логика целиком основана на булевой логике: электрический ток либо течет, либо нет; двоичное значение – либо единица, либо ноль; результат расчета – либо истина (true), либо ложь (false).

Не перепутайте булевы атрибуты и булевы значения. Вас можно понять, если вы подумаете, что булев атрибут будет принимать значения true и false. В действительности булево по природе само существование элемента: присутствует он или нет. Даже если напишете атрибуту значение, никакого эффекта это иметь не будет. Написать autoplay="false" или autoplay="no thanks" – то же самое, что написать autoplay.

Если вы используете синтаксис XHTML, можете написать autoplay="autoplay". Этот синтаксис используется в официальных документах Управления по управлению управлением избыточной информацией.

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

</audio>

Использование атрибута loop вместе с атрибутом autoplay заставит меня искать вас с удвоенной энергией.

Вырваться из-под контроля

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

</audio>

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

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

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

</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, возможно, стоит использовать preload="auto", но чем больше элементов audio появляется, тем больше интернет-канал посетителей вашей странички будет загружен из-за излишней предварительной подгрузки.

Его вам сразу вклю́чат, а может быть, включáт

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

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

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

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

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

</audio>

Браузер, который может проигрывать файлы Ogg Vorbis, не станет смотреть дальше первого элемента source. Браузер, который может проигрывать файлы MP3, но не может Ogg Vorbis, пропустит первый элемент source и проиграет файл во втором элементе source.

Можно помочь браузерам и указать MIME-типы для каждого исходного файла:

</audio>

Элемент source – самостоятельный (или «пустой») элемент, так что если вы используете синтаксис XHTML, не забудьте включить закрывающий слэш в конца каждого тега <source />.

Запасной вариант

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

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

<object type="application/x-shockwave-flash"data="player.swf?soundFile=witchitalineman.mp3">

<param name="movie"value="player.swf?soundFile=witchitalineman.mp3">

</object>

</audio>

В этом примере элемент object будет доступен только тем браузерам, которые не поддерживают элемент audio.

Можно пойти еще дальше. Элемент object, включающийся при «запасном варианте», тоже предоставляет вам возможность включить содержимое. Это значит, что, если больше ничего не срабатывает, можно дать старый проверенный вариант – гиперссылку:

<a href="witchitalineman.mp3">Скачать песню</a>

</object>

</audio>

В этом примере четыре уровня постепенной деградации.

1. Браузер поддерживает элемент audio и формат Ogg Vorbis.

2. Браузер поддерживает элемент audio и формат MP3.

3. Браузер не поддерживает элемент audio, но в нем установлен Flash-плагин.

4. Браузер не поддерживает элемент audio, и в нем не установлен Flash-плагин.

Доступ на все уровни

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

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

<p>I am a lineman for the county…</p>

</audio>

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

</audio>

<p>I am a lineman for the county…</p>

Video

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

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

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

</video>

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

</video>

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

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

<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 получили формы.

Веб-формы 2.0

Когда в веб-браузерах появился JavaScript, его немедленно стали использовать для двух задач: изменения картинки при наведении мышью и улучшения форм. Когда же в CSS появился псевдокласс:hover, веб-разработчикам перестало быть нужным использовать JavaScript для того, чтобы добиться просто изменения картинки при наведении.

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

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

Эти функции изначально были частью спецификации WHATWG, которая называлась Веб-формы 2.0 и основывалась на уже проделанной работе в W3C. Эта спецификация теперь включена в HTML5.

Placeholder

Вот типичная задача, которая часто используется для поисковых форм и обычно решается написанием скрипта для DOM:

1. Если у поля формы нет значения, вставить туда текст-заполнитель.

2. Когда пользователь перемещает фокус на это поле, убрать текст-заполнитель.

3. Если пользователь выходит из поля и в нем по-прежнему нет значения, снова поставить текст-заполнитель.

Текст-заполнитель обычно показывается шрифтом более светлого цвета, чем шрифт самого значения поля формы. Это реализуется с помощью CSS, JavaScript или обоими этими инструментами вместе.

В документе HTML5 вы можете просто использовать атрибут placeholder (рис. 4.01):

<label for="hobbies">Ваши хобби</label>

^{Рис. 4.01.} ^{«Стряхивать филинов с деревьев» появляется в поле input посредством атрибута placeholder}

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

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

Либо же вы можете сделать запасное решение на JavaScript. В этом случае вам нужно убедиться, что скрипт на JavaScript будет исполняться только в браузерах, которые не понимают атрибут placeholder.

Вот маленькая JavaScript-функция общего характера, которая тестирует, поддерживается тот или иной атрибут или нет:

function elementSupportsAttribute(element,attribute) {

var test = document.createElement(element);

if (attribute in test) {

return true;

} else {

return false;

}

Работает это так: в памяти создается «фантомный» элемент (в вашем документе его нет), а затем проверяется, есть ли в прототипе этого элемента свойство с тем же названием, что и атрибут, который вы передаете в эту функцию. Функция вернет true или false.

С помощью этой функции вы можете удостовериться, что JavaScript-решение будет исполняться только в тех браузерах, которые не поддерживают placeholder:

if (!elementSupportsAttribute('input','placeholder')) {

// Код запасного решения на JavaScript.

}

Autofocus

«Привет! Я автофокус. Может быть, вы помните меня по кнопочкам на сайтах: “Google: мне повезет” и “Twitter: что происходит?”»

Это простое типовое решение из одного шага, которое достаточно просто программируется на JavaScript:

1. Когда документ загрузился, автоматически поставить фокус на одно конкретное поле в форме.

HTML5 позволяет вам сделать это с помощью булева атрибута autofocus:

<label for="status">Что происходит?</label>

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

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

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

Как и в случае с атрибутом placeholder, вы можете протестировать, поддерживается ли autofocus, и, если нет, откатиться к решению на JavaScript:

if (!elementSupportsAttribute('input','autofocus')){

document.getElementById('status'). focus();

}

Атрибут autofocus работает не только на элементах input; его можно использовать на любом поле формы – как, например, textarea или select, но его можно использовать только один раз во всем документе.

Required

Один из самых распространенных случаев использования JavaScript – валидация форм на стороне клиента. И снова HTML5 перемещает это решение из JavaScript в разметку. Просто добавьте булев атрибут required:

<label for="pass">Ваш пароль</label>

Теоретически это дает указание браузерам не отправлять форму, если необходимые поля не заполнены. Даже несмотря на то, что пока браузеры этого не делают, уже сейчас можно использовать атрибут required в той валидации форм, которую вы пишете на JavaScript. Вместо того чтобы держать список всех требуемых полей в вашем скрипте или добавлять в разметку class="required", теперь вы можете проверять существование атрибута required.

Autocomplete

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

HTML5 позволяет вам отключить автозаполнение во всей форме или для какого-либо конкретного поля. Атрибут autocomplete не является булевым, но он может принимать только два возможных значения: “on” и “off ”:

По умолчанию браузеры будут считать, что autocomplete имеет значение “on”, и тем самым у них есть возможность осуществить предварительное заполнение формы.

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

Никакого запасного варианта на JavaScript для браузеров, которые не поддерживают атрибут autocomplete, нет. В этом случае новый атрибут HTML5 дополняет существующее поведение браузеров, а не заменяет решение на JavaScript.

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

Datalist

Новый элемент datalist позволяет вам скрестить обычный элемент input с элементом select. С помощью атрибута list вы можете сопоставить с полем формы список опций (рис. 4.02):

<label for="homeworld">Ваша родная планета</label>

<datalist id="planets">

</datalist>

^{Рис. 4.02.} ^{Новый элемент datalist}

Это позволяет юзерам выбрать опцию из приготовленного списка или ввести значение, которого в списке нет. Это очень полезно для ситуаций, которые обычно требуют отдельного поля в форме, озаглавленного: «если вы выбрали вариант “другое”, пожалуйста, укажите…» (рис. 4.03).

^{Рис. 4.03.} ^{Элемент datalist: показано, что юзер может ввести значение, которого нет в списке}

Элемент datalist – отличное, ненавязчивое дополнение к полю формы. Если браузер не поддерживает datalist, то поле ведет себя как обычное поле ввода.

Типы полей ввода

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

Поиск

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

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

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

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

Контакты

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

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

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

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

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

Разработчики 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>

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

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

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

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

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

Проверка

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

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

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

function inputSupportsType(test) {

var input = document.createElement('input');

input.setAttribute('type',test);

if (input.type == 'text') {

return false;

} else {

return true;

}

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

if (!inputSupportsType(‘range’)) {

// Код запасного решения на JavaScript.

}

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

Счетчики

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

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

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

Тип ввода number – гибрид text и range. Он позволяет пользователям вводить значения напрямую, как поле text, но также позволяет браузерам проверить, что в поле вводятся только численные значения, как в элементе управления range.

Дата и время

Один из самых популярных 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>

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

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

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

if (!inputSupportsType('date')) {

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

}

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

Выбор цвета

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

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

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

Сделай сам

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

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

<label for="zip">Почтовый индекс США</label>

Большую часть времени вам не придется использовать атрибут pattern. Что касается тех редких случаев, когда придется, – заранее вам сочувствую.

В ожидании будущего

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

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

Я уверен, что вы понимаете преимущества встроенных в браузер управляющих элементов для календарей и ползунков, но уверен, что у вас возникает вопрос: «Могу ли я применять к ним свои стили?»

Это хороший вопрос. На данный момент ответ: «нет». Придется смириться с решением рабочей группы CSS.

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

Я бы хотел, чтобы вы задали себе другой вопрос: «Нужно ли мне применять к элементам форм свои стили?»

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

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

Теперь давайте отложим формы в сторонку и посмотрим на новую сочную семантику, которая появилась в HTML5.

Семантика

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

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

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

Перефразируя Уинстона Черчилля, HTML – худшая форма разметки, если не считать всех прочих, что были испробованы человечеством.

Расширяемость

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

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

Если в этом месте вы думаете: «