Pull to refresh

HTML5 для веб-дизайнеров. Часть 3: Мультимедиа

Reading time14 min
Views8.3K
Original author: Jeremy Keith
HTML5 для веб-дизайнеров

  1. Краткая история языка разметки
  2. Модель HTML5
  3. Мультимедиа
  4. Формы 2.0
  5. Семантика
  6. HTML5 и современные условия


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

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

В спецификациях этих стандартов все еще есть пробелы. Так, если вы хотите сваять страницу с текстом и картинками, вы вполне обойдетесь HTML и CSS. Но если вам нужно опубликовать аудио или видео, тут неизбежно придется обратиться к сторонним технологиям — Flash или Silverlight.

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

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

Canvas


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

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

Сам по себе он очень прост. Все, что вы указываете в параметрах тега — это размеры холста:

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

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


<canvas id="my-first-canvas" width="360" height="240">
    <p>No canvas support? Have an old-fashioned image instead:</p>
    <img src="puppy.jpg" alt="a cute puppy">
</canvas>

image
Пользователи браузеров без поддержки
canvas увидят фотку милого щенка.


Вся работа по отрисовке возлагается на JavaScript. Перво-наперво, надо указать, с каким элементом мы работает и в каком контексте. «Контекст» в данном случае — это API, и он на сегодняшний день всего один — двухмерный (как видно, есть куда расти):

var canvas = document.getElementById('my-first-canvas');
var context = canvas.getContext('2d');

Теперь мы можем начать рисовать на этом двухмерном холсте элемента canvas, используя APIб задокументированный в спецификации HTML5. Набор инструментов здесь схож с тем, что вы найдете в любом графическом редакторе вроде Illustrator-а: линии, заливки, градиенты, тени, фигуры, кривые Безье. Разница лишь в том, что вместо рисования мышкой, нужно пользоваться командами в JavaScript.

Рисование кодом

Так цвет линий делается красным:

context.strokeStyle = '#990000';

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

strokeRect ( left, top, width, height )

Если вы хотите сделать этот прямоугольник высотой 50 пикселей, шириной 100, и расположить его на 20 пикселей от левого края элемента canvas и на 30 от верхнего, написать нужно следующее:

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


image
Прямоугольник, нарисованный командами JS в canvas-е.


Конечно, это элементарный пример. Двухмерный API включает множество разных методов: fillStyle, fillRect, lineWidth, shadowColor и еще много других.

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

И для чего же тогда? Какой с него толк?

Это здорово, что используя JavaScript и canvas, можно создавать векторные изображения на лету, но если они делаются сколько-нибудь сложными, эта работа не будет оправдывать себя.

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

Одним из первых примеров возможностей canvas-а стал проект Bespin от Mozilla Labs — приложение, являющееся простым текстовым редактором для кодинга, которое работает в окне браузера.

image
Веб-приложение Bespin, созданное при помощи элемента canvas.

Это очень мощная вещь. Она впечатляет. Но также, она — хорошим пример того, что не надо делать с canvas-ом.

Доступ запрещен

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

Каждая страница в сети может быть описана с помощью DOM — Document Object Model, «объектная модель документа». DOM может включать в себя много разных «узлов», самые важные из них — элементы, атрибуты и текстовые объекты. Этих трех видов «кирпичиков» достаточно, чтобы построить практически любую страницу, какую вы только себе можете представить. В свою очередь, элемент canvas не имеет DOM — его содержимое нельзя разделить на отдельные части и представить как дерево узлов.

Устройства для чтения с экрана и другие технологии для схожих задач основываются на возможности анализа DOM для понимания структуры и смысла документа. Нет DOM — нет доступа.

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

Умный холст

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

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

Допустим, у вас есть таблица с каким-то данными. Вы хотите проиллюстрировать наблюдающуюся в них тенденцию при помощи графика. В случае если данные статичны — можно просто сгенерировать график-картинку, используя Google Chart API, к примеру. Но если данные можно изменять по ходу дела, то было бы здорово создать график, который каждый раз отрисовывается по новой с учетом изменений. Canvas здесь отлично подойдет — можно использовать JavaScript для извлечения содержимого элемента table и создания на его основе математически рассчитанной иллюстрации.

Умные ребята из Filament Group даже разработали для этого плагин к jQuery, кстати говоря.

image
Примеры графиков, сгенерированных при помощи canvas


Есть и другой вариант. На самом деле, элемент canvas — не единственный API для генерации динамических изображений. SVG — Scalable Vector Graphics, масштабируемая векторная графика — XML формат, который может использоваться для описания тех же фигур, что и canvas. И исходя из сути XML как такового, содержимое SVG теоретически «понимаемо» для устойств для чтения с экрана.

Но на практике, SVG не произвел исключительного впечатления на разработчиков, в отличие от canvas, который, хоть и появился совсем недавно, уже широко поддерживается доступными браузерами. Его возможности даже реализуемы в IE, при помощи дополнительной JavaScript-библиотеки.

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

Это может показаться слегка бессистемным и неорганизованным, но факт — так рождаются многие наши стандарты. Взять хотя бы лежащий в основе Ajax объект XMLHttpRequest, впервые реализованный еще в конце прошлого века в Microsoft Internet Explorer 5.

В мире браузеров, где выживает наиболее приспособленный, canvas в данный момент набирает силу и популярность. Как только он станет более «открытым» для доступа извне, его позиции будут надежно закреплены.

Аудио


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

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

И теперь HTML5 планирует лишить его этого титула.

Вставка аудио-файла на страницу в HTML5 выглядит просто:

<audio src="witchitalineman.mp3">
</audio>

Но это слишком просто. Вам наверняка понадобится немного больше возможностей.

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

<audio src="witchitalineman.mp3" autoplay>
</audio>

Если я увижу, что вы используете autoplay в подобных целях, не ждите от меня пощады при встрече.

Заметьте, что этот параметр не имеет значения; в смысле — используется сам по себе. Штуки такого рода называется булевы параметры, в честь величайшего математика Джоржа Буля. На разработанной им двоичной логике основаны все компьютерные системы, где базовые значения переменных всегда либо ноль, либо единица, true или false.

Не следует однако путать булевы параметры с булевыми значениями. Простительно подумать, что булев параметр обязан принимать значение true или false, но это не так. Сама суть его существования уже булева, то бишь бинарна, — он либо есть (true), либо его нет вовсе (false). Даже если вы добавите к такому атрибуту какое-либо значение, оно не даст никакого эффекта: autoplay=«false» или autoplay=«no thanks» — то же самое, что и просто autoplay.

Если же вы пользуетесь исключительно синтаксисом XHTML, то для вас — autoplay=«autoplay». Одобрено Международным Департаментом Департамента Избыточности.

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

<audio src="witchitalineman.mp3" autoplay loop>
</audio>

Сочетание этих параметров дополнительно уменьшит ваши шансы остаться в живых при встрече со мной.

Все под контролем

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

<audio src="witchitalineman.mp3" controls>
</audio>

Он включит отображение стандартных браузерных контролов для кнопки «плей-пауза» и регулятора громкости.

image
controls отображает «родной» браузеровский интерфейс управления воспроизведением


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


<audio id="player" src="witchitalineman.mp3">
</audio>
<div>
    <button onclick="document.getElementById('player').play()">
    Play
    </button>
    <button onclick="document.getElementById('player').pause()">
    Pause
    </button>
    <button onclick="document.getElementById('player').volume += 0.1">
    Volume Up
    </button>
    <button onclick="document.getElementById('player').volume -= 0.1">
    Volume Down
    </button>
</div>

image
Кастомные контролы, сделанные при помощи элементов button.


Буферизация

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

Это был бы очень полезный параметр, но, к сожалению, Safari пошел дальше. Это браузер начал презагружать аудио файла, не обращая внимания на autobuffer. А так как — вы помните — autobuffer является булевым параметром, никак нельзя использовать его, чтобы запретить презагрузку: autobuffer=«false» — это то же, что и autobuffer=«true», как и вообще любое значение (описание бага).

Так что теперь autobuffer был заменен на параметр preload. Он не булев, он принимает одно из следующих трех значений: none, auto и metadata. Используя preload=«none», мы явно говорим браузеру, что презагружать этот файл не нужно.

<audio src="witchitalineman.mp3" controls preload="none">
</audio>

Если у вас на странице только один элемент audio, preload=«auto» вполне оправдан и логичен. Но не стоит делать этого если их несколько, дабы не обижать посетителей с не самым быстрым и/или безлимитным интернетом.

Я спою «поребрик», ты споешь «бордюр»

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

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

Существует, конечно, и другие форматы. Например, кодек Vorbis — обычно дающий на выходе файлы .ogg — не обременен никакими патентами. Этот работает в Firefox, но, в свою очередь, не поддерживается Safari.

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

<audio controls>
	<source src="witchitalineman.ogg">
	<source src="witchitalineman.mp3">
</audio>

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

Можно помочь им в выборе, указав mime-type для каждого файла:

<audio controls>
	<source src="witchitalineman.ogg" type="audio/ogg">
	<source src="witchitalineman.mp3" type="audio/mpeg">
</audio>

Элемент source — это одиночный, «неконтейнерный» элемент, так что если вы пользуетесь XHTML-синтаксисом, тег нужно закрывать косой чертой: <source/>.

Для не столь одаренных

Возможность указать несколько source-ов — это здорово, но ведь есть браузеры, которые не поддерживает элемент audio совсем. Ну, вы поняли, о ком я.

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

<audio controls>
	<source src="witchitalineman.ogg" type="audio/ogg">
	<source src="witchitalineman.mp3" type="audio/mpeg">
	<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 controls>
	<source src="witchitalineman.ogg" type="audio/ogg">
	<source src="witchitalineman.mp3" type="audio/mpeg">
	<object type="application/x-shockwave-flash" data="player.swf?soundFile=witchitalineman.mp3">
		<param name="movie" value="player.swf?soundFile=witchitalineman.mp3">
		<a href="witchitalineman.mp3">Download the song</a>
	</object>
</audio>

Таким образом, приорететы идут в следующем порядке:

  1. Звук в формате Ogg Vorbis через элемент audio
  2. Звук в формате MP3 через элемент audio
  3. Звук через Flash
  4. Ссылка для скачивания файла напрямую

Доступность содержимого

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

<audio controls>
	<source src="witchitalineman.ogg" type="audio/ogg">
	<source src="witchitalineman.mp3" type="audio/mpeg">
	<p>I am a lineman for the county...</p>
</audio>

В данном случае содержимое <p> отобразится только если браузер посетителя не поддерживает элемент audio. Это не будет полезно для глухого пользователя с современным браузером. К тому же, текст песни может быть полезен и всем остальным — зачем же его тогда прятать?

<audio controls>
	<source src="witchitalineman.ogg" type="audio/ogg">
	<source src="witchitalineman.mp3" type="audio/mpeg">
</audio>
<p>I am a lineman for the county...</p>

Видео


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

Элемент video работает по схожей схеме с audio: те же параметры autoplay, loop, preload; такая же система с атрибутом src или несколькими вложенными элементами source; точно так же можно добавить стандартный интерфейс управления при помощи controls, или сделать свой собственный.

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

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

Что еще можно интересного сделать — это добавить превьюшку в виде картинки, используя параметр poster:

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

image
Превью отображается до того, как видео начало проигрываться.


Не самые приятные новости в том, что борьба форматов в среде видео еще более жесткая, чем среди аудио. Главные игроки: MP4 (обременен патентом) и Theora 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">Download the movie</a>
	</object>
</video>

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

Модно, стильно, нативно

Возможность вставлять видео стандартными средствами языка разметки может быть самым потрясающим нововведением после создания элемента img. Даже такие крупные игроки как Google не стесняются проявлять энтузиазм по этому поводу. Вот, например, что им задумано для нового YouTube-а: www.youtube.com/html5

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

image
Элемент video встречает CSS3. Попробуйте сделать такое с плагином.


Поддержка аудио и видео как часть HTML5 получила наши одобрение и восторг. Но ведь мы знаем, что всемирная сеть — не столько презентационная среда, она еще и интерактивная. А самым старым, но бессменно мощным, инструментом достижения интерактивности на веб-страницах всегда были формы. В следующей главе мы рассмотрим, какие новые возможности для них открывает HTML5.
Tags:
Hubs:
Total votes 113: ↑111 and ↓2+109
Comments30

Articles