Страница 3 из 4
Эта точка зрения четко выражена в принципе устройства, озаглавленном «Приоритет пользователей», в котором сказано: «В случае конфликта ставьте интересы пользователей выше разработчиков, разработчиков – выше конкретных реализаций, реализации – выше спецификаций, спецификации – выше теоретической чистоты».
Ян Хиксон несколько раз говорил, что настоящие судьи в споре того, что окажется в HTML5, а что нет, – разработчики браузеров. Если компания-разработчик браузера откажется поддерживать какое-либо предложение, нет смысла добавлять это предложение в спецификацию, потому что тогда спецификация окажется всего лишь фиктивным документом. Согласно приоритету пользователей наш (веб-разработчиков) голос имеет еще больший вес. Если мы откажемся использовать какую-либо часть спецификации, это также сделает спецификацию фиктивной.
Ближе к реальности
Определяющим фактором в разработке HTML5 стало постоянное внутреннее напряжение. С одной стороны, эта спецификация должна быть достаточно мощной, чтобы поддерживать создание веб-приложений. С другой стороны, HTML5 должна поддерживать существующее содержимое даже с учетом того, что бо́льшая часть существующего содержимого – неудобоваримая каша. Если спецификация слишком отклонится в одном направлении, ее постигнет та же судьба, что и XHTML 2. Но если она пойдет слишком далеко в другом направлении, тогда выйдет, что спецификация будет рекомендовать использование тегов <font> и таблиц для разметки – поскольку в конце концов именно с использованием этих приемов построено огромное количество веб-страниц.
Здесь нужно выдержать очень тонкий баланс, и это требует прагматического, уравновешенного подхода.
Обработка ошибок
Спецификация HTML5 не просто объявляет, что должны делать браузеры, когда они обрабатывают синтаксически правильную разметку. Впервые за всю историю HTML спецификация также объявляет, что́ браузеры должны делать, когда им встречаются документы с ошибками разметки.
До сих пор разработчикам браузеров приходилось разбираться, что делать с ошибками, каждому самостоятельно. Обычно это означало, что нужно было применять реверс-инжиниринг и реализовывать примерно то, что делал в случае ошибок самый популярный браузер. Не самое продуктивное использование времени разработчиков браузеров. Гораздо лучше было бы не тратить время на то, чтобы дублировать то, как конкурент обрабатывает ошибочную разметку, а разрабатывать вместо этого новые функции.
Определение того, как нужно обрабатывать ошибки, в HTML5 – невероятно амбициозная задача. Даже если бы в HTML5 были только элементы и атрибуты из HTML 4.01, без добавления каких бы то ни было новых возможностей определить то, как нужно обрабатывать все ошибки, к 2012 году, – все равно было бы геркулесовым трудом.
Возможно, обработка ошибок не очень-то заинтересует веб-разработчиков, особенно если мы сразу настраиваемся на то, что пишем валидные и синтаксические корректные документы, но для разработчиков браузеров это очень важно. Если предыдущие спецификации разметки писались для авторов, то HTML5 написан и для авторов, и для разработчиков реализаций. Держите это в уме, когда штудируете спецификацию. Это объясняет, почему спецификация HTML5 настолько велика и почему она написана с таким уровнем детализации, который, кажется, обычно пишется для филателистов, любящих играть в шахматы, перебирая свою коллекцию игрушечных поездов.
Доктайп, скажите честно, я буду жить?
Декларация типа документа, или сокращенно «доктайп», обычно используется для того, чтобы определить, какой именно версией разметки написан документ.
Доктайп для HTML 4.01 выглядит так (переносы строки обозначены»):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Вот доктайп XHTML 1.0:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Не сильно человекочитаемо, но по-своему эти доктайпы просто говорят: «этот документ написан на HTML 4.01» и «и этот документ написан на XHTML 1.0».
Наверное, вы ожидаете, что в доктайпе, объявляющем «этот документ написан на HTML5», где-то будет цифра «пять». Не будет. Доктайп для HTML5 выглядит так:
<!DOCTYPE html>
Он настолько короткий, что я даже могу его запомнить.
Но это же безумие! Если в доктайпе нет номера версии, как мы сможем определить следующие версии HTML?
Когда я в первый раз увидел доктайп HTML5, я подумал, что это верх гордыни. «Неужели они действительно думают, – спросил я себя, – что это будет последняя спецификация разметки, написанная на Земле?»
В общем, казалось, что это случай из учебника по мышлению «с нуля».
На самом деле, однако, доктайп HTML5 весьма прагматичен. Так как HTML5 должен поддерживать существующее содержимое, этот доктайп может быть применен и к существующему документу на HTML 4.01 или XHTML 1.0. Любая будущая версия HTML тоже должна будет поддерживать существующее содержимое, написанное на HTML5, так что сам концепт применять номера версий к документам разметки имеет значительный изъян.
На деле доктайпы не имеют принципиального значения. Например, вы поставили в документ доктайп HTML 4.01. Если в этом документе окажется элемент из другой спецификации – например, из HTML 3.2 или из HTML5, – браузер все равно отобразит эту часть документа. Браузеры поддерживают функциональность, а не доктайпы.
Декларации типа документа предназначались не для браузеров, а для валидаторов. Единственный случай, в котором браузер обращает какое-либо внимание на доктайп, – когда он «переключает доктайп», – это маленький умный хак, который переключает режим отображения между нестандартным (quirks mode) и стандартным режимами в зависимости от присутствия подходящего доктайпа.
Минимальная информация, необходимая для того, чтобы браузер точно отобразил страницу в стандартном режиме, – и есть доктайп HTML5. На самом деле это вообще единственная причина включать какой-либо доктайп. HTML-документ без доктайпа HTML5 все равно вполне может быть валидным 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">