Pull to refresh

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

Reading time 12 min
Views 14K
Original author: Jeremy Keith
HTML5 для веб-дизайнеров

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


Великая Французская революция была временем радикальных политических и социальных преобразований. Времени как такового они тоже коснулись: в определенный период своего существования Французская Республика жила по новой системе — в сутках было 10 часов по сто минут каждый. Очевидно, что она была была куда логичнее и «правильнее» привычной шестидесятеричной.

Вместе с тем, она была полным провалом. Никто ей не пользовался.

То же самое можно сказать и про XHTML 2. W3C только лишний раз доказал то, чему нас научил урок послереволюционной Франции: изменить привычки людей по приказу очень-очень трудно.


Принципы модели


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

Тогда как XHTML 2 намеревался забить на все, что было до него, и начать по-новой, HTML5 — это надстойка для существующих спецификаций. В нем сохранилось и поддеживается многое из HTML 4.01.

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

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

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

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

Без крайностей


Разработка HTML5 сопряжена с постоянным внутренним напряжением и противоречием. С одной стороны, спецификация должна быть достаточно функциональной и мощной, чтобы стать надежной платформой для создания веб-приложений. С другой стороны, HTML5 должен быть способен поддерживать уже существующее содержимое сети, даже если там по нынешним сплошной беспорядок и месиво в коде. Если спецификация отклонится слишком сильно в одно направление, ее ждет судьба XHTML2. Если в другое — краеугольным камнем снова станут тег <font> и таблицы как средство разметки, ведь с их помощью, в конце концов, построено огромное количество существующих веб-страниц.

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

Обработка ошибок


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

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

Решение ввести стандарты для этой процедуры в HTML5 очень амбициозно. Даже если бы набор тегов и атрибутов в этой версии ничем не отличался от того, что в HTML 4.01, разработка одного только единого свода правил обработки ошибок к 2012-ому году была бы все равно что сизифов труд.

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

Выкладывай, Док(тайп)


Доктайп (doctype, Document Type Declaration) — традиционный способ указывать тип языка разметки, который используется на данной странице.

Так выглядит доктайп для HTML 4.01:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3c.org/TR/html4/strict.dtd">


Так — для XHTML 1.0:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict //EN" "http://www.w3c.org/TR/xthml1/DTD/xhtml1-strict.dtd">


Совершенно нечитаемо для человека, но, как ни крути, эдакий способ по-своему сказать просто «Эта страница написана на HTML 4.01» или «Эта страница написана на XHTML 1.0».

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

<!DOCTYPE html>


Наконец-то это можно будет выучить наизусть.

Но, блин, как это так? Тут не указан номер версии, как же мы будем обозначать последующие инкарнации HTML? Когда я впервые увидел этот новый вид доктайпа, я подумал «Что за блажь, они действительно хотят этим сказать, что это финальная версия языка разметки, после которой уже ничего никогда не будет нужно?»

На самом деле, идея проста и очень прагматична. Задача HTML5 — поддерживать существующие HTML 4.01 и XHTML 1.0 страницы, и этого доктайпа им хватит. Новые версии HTML, в свою очередь, должны будут поддерживать HTML5, оттого включать в него постоянно порядковый номер совершенно бессмысленно.

А вообще, и доктайпы сами по себе то и не так важны. Скажем, написали вы страницу с доктайпом от HTML 4.01, а потом взяли и добавили туда элементов из другой спецификации — пусть HTML 3.2, пусть HTML5, не суть. Браузер все равно никуда не денется и обработает их как умеет. Браузеры поддерживают элементы и фичи, а не доктайпы.

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

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

Незачем усложнять


В HTML5 упростили не только доктайп.

Если вы хотите обозначит кодировку для своей страницы, лучший способ это сделать — убедиться, что сервер отдает корректное значение в Content-Type. Чтобы быть совсем уверенным, можно воспользоваться тегом <meta>. Так это было раньше:

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


Так это в HTML5:

<meta charset="UTF-8">


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

Тегу <script> тоже вполне можно разрешить похудет. Часто в него добавляют параметр type со значением text/javascript:

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


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

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


Точно так же нет смысла в параметре type со значением text/css, когда вы прикрепляете таблицу стилей. Можно просто написать:

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


Синтаксис: делай как привык


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

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

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

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

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

XHTML 1.0 придерживается синтаксиса XML: теги всегда в нижнем регистре, значения параметров только в кавычках, все контейнерные элементы обязательно закрываются. И одиночные тоже — перед закрывающей скобкой должен стоять слеш (<br> → <br />).

В HTML5 вы решаете сами: верхний регистр — нижний, кавычки — без кавычек, закрывающийся или нет. Как вам больше нравится.

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

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

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

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


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

В HTML5 нет изъятых элементов или параметров, вместо них только устаревшие.

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

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

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

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

Разлука будет без печали

Признаны устаревшими теги: frame, frameset и noframes. По ним скучать не будут.

Устаревшим является тег acronym, что наконец-то положит конец длившимся годы холиварам и спорам. Не стоит его оплакивать, просто используйте тег abbr вместо него. И, да, я знаю разницу между аббревитурой и акронимом: акронимы — это аббревиатуры, которые произносятся целиком, как слово, а не по буквам (например, НАТО). Не каждая аббревиатура — акроним, но каждый акроним — аббревиатура, потому здесь достаточно одного тега.

Оформляющие элементы font, big и center тоже устарели, и, на самом деле, это случилось давно — еще с приходом CSS, где аналогичные эффекты можно назначать быстрее и легче. По тем же причинам, с нами больше нет параметров bgcolor, cellspasing, cellpadding и valign. Вместо них пользуйтесь CSS.

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

Подмены понятий


Элемент big устарел, но вот small — нет. Такая непоследовательность оправдывается за счет того, что значение последнего было пересмотрено. Это теперь не физическое «сделать текст мельче», а семантический «мелкий шрифт». Ну, вы поняли, — условия пользования, сноски для «звездочек» и так далее.

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

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

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

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

…конец цитаты

Значение элемента cite тоже было слегка изменено. Если раньше он означал «ссылка на источник», то теперь это — «заголовок источника». Очень часто при цитировании источником будет как раз заголовок книги, фильма или чего угодно, на что мы ссылаемся. Однако точно так же это может быть и имя человека. В HTML5, при этом, использовать личные имена внутри элемента cite противоречит спецификации.

Объясняется это так: браузеры делают содержимое тега <cite> курсивным. Заголовки работ обычно выделяются курсивом. Имена людей курсивом не выделяются. Поэтому элемент cite не должен применяться для ссылки на конкретного человека.

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

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

<a> на стероидах

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

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

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

<h2><a href="/about">Обо мне</a></h2>
<p><a href="/about">Узнайте, чем я живу</a></p>

В HTML5 эти несколько элементов можно завернуть в один тег <a>:

<a href="/about">
	<h2>Обо мне</h2>
	<p>Узнайте, чем я живу</p>
</a>

Единственное ограничение: нельзя запихать внутрь <a&gt еще один <a&gt.

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

Новые игрушки: API для JavaScript


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

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

Может показаться странным, что спецификация языка разметки будет включать в себя документацию по JavaScript, но не стоит забыть, что HTML5 начинался с проекта Web Apps 1.0, а JS — неотъемлемый компонент веб-приложений.

Целые разделы спецификации посвящены новым API, предназначенным для разработки оных. UndoManager позволяет следить за чередой изменений в документе. Есть раздел, затрагивающий работу с веб-приложениями в оффлайне, используя cache manifest. Drag-n-Drop тоже подробно описан.

Как всегда, если где-то есть уже существующие реализации, спецификация скорее основывается на них, нежели чем переизобретает велосипед. Например, API для drag-n-drop в Internet Explorer существовал уже долгое время и послужил основной для того, что включено в HTML5. Стоит, впрочем, заметить, что Майкрософтские API, мягко говоря, довольно проблемны, и иногда переизобретение велосипеда может быть оправдано, особенно если все, что вы имеете, — велосипед с квадратными колесами, без седла и половиной руля.

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

Тем временем, у нас полно увлекательнейших вещей в непосредственно HTML5. И восторг по их поводу начинается уже со следующей главы.
Tags:
Hubs:
+118
Comments 57
Comments Comments 57

Articles