Кит Джереми - HTML5 для веб-дизайнеров Страница 2

В октябре 2006 года сэр Тим Бернерс-Ли написал пост в блоге, в котором признал, что попытка заставить веб перейти с HTML на XML не имеет шансов на успех. Несколько месяцев спустя W3C выпустил новый договор для рабочей группы HTML. Вместо того чтобы начинать с нуля, они мудро решили, что в качестве фундамента для любой будущей версии HTML нужно использовать наработки WHATWG.

Эта остановка и новый запуск привели к несколько запутанной ситуации. Получилось, что W3C одновременно работал над двумя разными, несовместимыми типами разметки: XHTML 2 и HTML 5 (обратите внимание на пробел перед пятеркой). В то же время отдельная организация, WHATWG, работала над спецификацией под названием HTML5 (без пробела), которая должна быть использована в качестве основы для одной из спецификаций W3C!

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

XHTML умер: да здравствует синтаксис XHTML

Туман неразберихи начал рассеиваться в 2009 году. W3C объявил, что договор на XHTML 2 не будет продлеваться. Формат был мертвым уже несколько лет, и это объявление стало только официальным свидетельством о смерти.

Как ни странно, смерть XHTML 2 не прошла незамеченной. Напротив, противники XML отреагировали на нее злорадно и использовали это объявление для того, чтобы высмеять всех, кто когда-либо использовал XHTML 1, – даже несмотря на то, что между XHTML 1 и XHTML 2 не было практически ничего общего.

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

Как вы скоро увидите, это не обязательно так. Вы можете писать на HTML5 и небрежно, и строго – как захотите.

Развитие HTML5

Текущее состояние HTML5 не такое запутанное, как было когда-то, но все равно не до конца понятное.

Над HTML5 работают две группы. WHATWG создает спецификацию HTML5 в рамках процесса «утвердить, потом пересмотреть». Рабочая группа по HTML W3C берет эту спецификацию и проводит ее через процесс «пересмотреть, потом утвердить». Как вы легко можете представить, это непростой политический союз. По крайней мере, кажется, наконец появилось единодушие по этому назойливому вопросу – с пробелом или без пробела? (На тот случай, если вам вдруг интересно, HTML5 решили писать без пробела.)

Пожалуй, самая сбивающая с толку проблема для тех веб-разработчиков, которые пробуют кончиком ноги воду HTML5, – ответ на вопрос «когда он будет готов?»

Ян Хиксон в интервью сказал, что ожидает, что HTML5 получит статус предложенной рекомендации[1] в 2022 году. За этим последовала волна общественного негодования от ряда веб-разработчиков. Они не понимали, что значит «предложенная рекомендация», но уж точно знали – на руках нет столько пальцев, чтобы пересчитать, сколько лет пройдет до 2022 года.

Для негодования не было повода. В данном случае для того чтобы получить статус «предложенной рекомендации», нужно иметь две полных реализации HTML5. Учитывая объем спецификации, эта дата невероятно амбициозна. В конце концов, у браузеров не самая лучшая репутация в плане реализации существующих стандартов. Internet Explorer потребовалось больше десятилетия, чтобы добавить поддержку – всего-то – элемента abbr.

Та дата, которая действительно имеет значение для HTML5, – 2012 год. В этом году спецификация должна стать кандидатом в рекомендации. Это на жаргоне стандартов значит «сделано и отшлифовано».

Но даже эта дата не особенно важна для веб-разработчиков. Имеет значение тот момент, когда браузеры начнут поддерживать функциональность HTML5. Мы начали использовать части спецификации CSS 2.1, как только начали выпускаться браузеры с поддержкой этих частей. Если бы мы ждали, пока каждый браузер начнет полностью поддерживать CSS 2.1, и только потом стали его использовать, мы ждали бы до сих пор.

С HTML5 ровно то же самое. Не будет никакого четкого момента, когда мы могли бы объявить, что язык готов к использованию. Однако, мы можем начинать использовать части спецификации по мере того, как веб-браузеры начинают поддерживать эти функции.

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

2. Устройство HTML5

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

Десятичное время было полным провалом. Никто не стал использовать эту систему. То же можно сказать о XHTML 2. W3C на своем опыте усвоила урок революционной Франции: изменять существующее поведение в высшей степени сложно.

Принципы устройства

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

Если XHTML 2 намеревался отбросить все то, что было до него, то HTML5 основывается на уже существующих спецификациях и реализациях. Бóльшая часть HTML 4.01 вошла в HTML5.

В числе других принципов разработки есть, например, такие: «Не изобретайте велосипед» и «Асфальтируйте тропинки» – то есть если среди веб-разработчиков есть широко распространенный способ выполнять задачу – даже если он необязательно лучший, – именно этот способ должен быть записан в HTML5. Сказать по-другому: «Если ничего не ломается, не начинай чинить».

Многие из этих принципов дизайна могут быть вам знакомы, если вы когда-либо заглядывали в сообщество по микроформатам (http://microformats.org). HTML5-сообщество разделяет этот же самый прагматичесный подход: нужно запустить формат в реальный мир, а не волноваться слишком сильно из-за теоретических проблем.

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

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

Ближе к реальности

Определяющим фактором в разработке HTML5 стало постоянное внутреннее напряжение. С одной стороны, эта спецификация должна быть достаточно мощной, чтобы поддерживать создание веб-приложений. С другой стороны, HTML5 должна поддерживать существующее содержимое даже с учетом того, что бо́льшая часть существующего содержимого – неудобоваримая каша. Если спецификация слишком отклонится в одном направлении, ее постигнет та же судьба, что и XHTML 2. Но если она пойдет слишком далеко в другом направлении, тогда выйдет, что спецификация будет рекомендовать использование тегов <font> и таблиц для разметки – поскольку в конце концов именно с использованием этих приемов построено огромное количество веб-страниц.

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

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

Спецификация HTML5 не просто объявляет, что должны делать браузеры, когда они обрабатывают синтаксически правильную разметку. Впервые за всю историю HTML спецификация также объявляет, что́ браузеры должны делать, когда им встречаются документы с ошибками разметки.

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

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