Текст книги "HTML5 для веб-дизайнеров"

Будем проще

Доктайп – не единственная вещь, оказавшаяся упрощенной в HTML5.

Если вы хотите особо указать кодировку вашего документа разметки, лучший способ сделать это – проверить, что ваш сервер посылает правильный HTTP-заголовок Content-Type. Если вы хотите быть вдвойне уверенным, можно также определить кодировку с помощью тега <meta>. Вот как выглядит декларация meta для документа, написанного на HTML 4.01:

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">

Вот гораздо более легкий для запоминания способ сделать то же самое в HTML5:

<meta charset="UTF-8">

Как и с доктайпом, это упрощенное объявление кодировки содержит минимальный набор символов, который необходим браузерам для правильной интерпретации.

Тег <script> – еще одно место, где мы можем позволить себе немножко сбросить вес. Обычная практика – добавлять к элементам script атрибут type со значением «text/javascript»:

<script type="text/javascript" src="file.js"></script>

Браузерам этот атрибут не нужен. Они и так примут за данность, что этот скрипт написан на JavaScript, самом популярном языке скриптов в вебе (давайте будем честными – на единственном языке скриптов в вебе):

<script src="file.js"></script>

Точно также не нужно указывать значение type – «text/css» каждый раз, когда вы делаете ссылку на CSS-файл:

<link rel="stylesheet" type="text/css" href="file.css">

Можно просто написать:

<link rel="stylesheet" href="file.css">

Синтаксис: размечайте, как хотите

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

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

В сердце спора о значимых пробелах лежит фундаментальный философский вопрос: должен ли язык навязывать определенный стиль написания кода – или авторы должны иметь возможность писать в любом стиле, в каком хотят?

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

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

XHTML 1.0 обязывает следовать синтаксису XML. Все теги должны быть написаны в нижнем регистре. Все атрибуты должны быть в кавычках. У всех элементов должен быть закрывающий тег.

В особенном случае самостоятельных элементов, например br, требование закрывающего тега заменяется требованием закрывающей косой черты: <br/>.

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

Я использовал доктайп XHTML 1.0 в течение многих лет. Мне нравится, что я должен писать в каком-то одном специфическом стиле, и мне нравится, что валидатор W3C обязывает меня писать в этом стиле. Теперь, когда я использую HTML5, я сам должен обязать себя писать в том стиле, в каком хочу.

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

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

Кто напишет такую программу, заслужит вечное уважение и восхищение веб-разработчиков по всему миру.

Мы так не разговариваем

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

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

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

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

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

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

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

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

Устарел элемент acronym, освободив таким образом годы времени на споры, которые можно использовать с бо́льшим толком: хотя бы рассчитать наконец теоретически возможную плотность одновременного количества ангелов на булавочной головке стандартного размера[2]2
  В крупнейшем схоластическом труде Средневековья, «Сумме теологии» Фомы Аквинского, содержится ряд логических умозаключений о природе мира, Бога и в том числе ангелов (например: «Может ли ангел переместиться из одной точки в другую, не проходя нигде в середине между ними?»). Мыслители эпохи Просвещения, критиковавшие абсурдные с их точки зрения построения томизма, сочинили иронический «вопрос»: «Сколько ангелов могут одновременно танцевать на кончике иглы, не задевая друг друга?» Хотя у Фомы Аквинского нигде нет подобного образа, схожий («в раю тысяча душ может поместиться на кончике одной иглы») встречается в одном из немецких мистических текстов XIV в. Прим. перев.


[Закрыть]. Не плачьте по элементу 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]3
  В англоязычной традиции. Отсутствие такой практики на других языках (в частности, на русском) – еще один аргумент в пользу точки зрения автора. Прим. перев.


[Закрыть], а имена людей – нет, таким образом, элемент cite не должен использоваться для того, чтобы размечать имена авторов.

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

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

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

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

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

<h2><a href="/about">Обо мне</a></h2>

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

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

<a href="/about">

<h2>Обо мне</h2>

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

3. Мультимедиа

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

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

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

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

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

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

Canvas

Когда браузер 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]4
  Полная ссылка: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html


[Закрыть]

В 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]5
  Полная ссылка: http://www.w3.org/Wai/pf/html-task-force


[Закрыть].

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