ХО-ХО-ХО! Праздник к нам приходит! Всегда coca-co… HTML5!
Выпал снежок и как-то незаметно пришло праздничное, предновогоднее настроение. Чтобы как-то поддержать праздничный дух, мы решили сделать небольшой сюрприз от издательства и порадовать наших читателей бесплатной электронной книгой «HTML5. Руководство разработчика» (DIVE INTO HTML5). Оригинал книги также есть в бесплатном варианте в Интернете.
Прежде чем скачать книгу целиком, предлагаем вам познакомиться с первой главой:

Глава 1. Как мы сюда попали?

Приступим

Недавно я прочел высказывание одного разработчика для платформы Mozilla, где говорится о той напряженности, которая всегда сопутствует разработке стандартов:

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

Пока я буду рассказывать, как появился HTML5, помните эти слова.

MIME-типы

Книга, которую вы держите в руках, посвящена HTML5, а не предшествующим версиям стандарта HTML и тем более не XHTML. Но, чтобы ясно проследить историю HTML5 и увидеть причины, предшествующие его появлению, нужно сначала овладеть кое-какими техническими деталями, в частности получить понятие о MIME-типах.
Каждый раз, когда ваш браузер пытается загрузить страницу, сервер, прежде чем отослать клиентской программе код самой страницы, отправляет ей ряд заголовков. Пользователь обычно не видит этих заголовков, хотя в некоторых программах для веб-разработчиков предусматривается возможность их отображения. Заголовки важны постольку, поскольку они сообщают браузеру, как воспринимать код посылаемой вслед за ними страницы. Самый информативный заголовок называется Content-Type и выглядит, например, так:

Content-Type: text/html

Значение text/html называется типом содержимого, или MIME-типом загружаемой страницы. Только данный заголовок определяет, каково содержание отдельного ресурса и, следовательно, как этот ресурс должен выводиться на экран. У изображений собственные MIME-типы (image/jpeg — для картинок в формате JPEG, image/png — для формата PNG и т. д.). Собственными MIME-типами оснащены файлы JavaScript, таблицы стилей CSS и, в общем-то, все, что есть в Сети.
На самом деле все чуть сложнее, чем рассказано выше. Самые ранние веб-серверы, под которыми я понимаю веб-серверы 1993 года и нескольких последующих лет, не отправляли заголовки Content-Type, потому что те были изобретены только в 1994 году. Ради совместимости, во имя которой, кстати, с 1993 года по сей день делалось и делается очень много всего, отдельные популярные браузеры при определенных условиях игнорируют заголовки Content-Type. Это называется контент-сниффингом. Но общее правило таково, что любой фрагмент содержимого Сети, будь то HTML-страница, изображение, сценарий, видеозапись, PDF-документ или что-то еще под собственным URL-адресом, посылается клиентской программе с предварительным уведомлением о MIME-типе в заголовке Content-Type. Хорошенько запомните эту информацию, так как она еще пригодится.

Большое отступление о том, как появляются стандарты

Откуда взялся тег <img>? Не думаю, что вы хоть иногда задавались подобным вопросом. Очевидно, кто-то его создал. Такие вещи не берутся ниоткуда. Из всех элементов и атрибутов HTML, которыми вы в разное время пользовались, абсолютно каждый был когда-то кем-то создан. Этот кто-то придумал, как должен работать элемент или атрибут, и письменно сформулировал свои мысли. Такого рода люди, бесспорно, умнее нас с вами, но они тоже обычные люди.
Если стандарт разрабатывался открыто, то можно вернуться в прошлое и увидеть, как рождалась идея того или иного пункта спецификации. Обсуждения ведутся в почтовых рассылках, а их архивы обычно имеют интерфейс поиска. Чтобы ответить на вопрос о теге <img>, я решил немного позаниматься «электронной археологией» и погрузился в толщу времен, когда еще не существовало Консорциума Всемирной паутины (W3C), а все веб-серверы мира можно было пересчитать по пальцам. Речь идет о первых днях Интернета.
25 февраля 1993 года Марк Андрессен (Marc Andreessen) написал:

Предлагаю новый опциональный HTML-тег:
IMG
При нем должен обязательно указываться аргумент SRC=" url". Тег отсылает к файлу растрового изображения (bitmap или pixmap). Браузер будет запрашивать этот файл в Сети, распознавать как изображение и вставлять в текст сообразно месту
тега в коде страницы.
Пример использования:

<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">
(Закрывающий тег не требуется.)

Как и любое другое содержимое, этот тег может быть вложен внутрь якоря. Тогда изображение станет чувствительным к активизации, как и обычная текстовая ссылка. Следует предоставить браузерам свободу выбора графических форматов, которые будут в них поддерживаться. Удачным выбором мне представляются, например, Xbm и Xpm. Если браузер
не умеет отображать данный формат, пусть он делает то, что разработчикам заблагорассудится предусмотреть на этот случай (так, в X Mosaic будет выводиться растровая картинка, замещающая нужное изображение).
Данная функциональность будет реализована в X Mosaic. Мы работаем над ней и собираемся использовать по крайней мере внутри команды разработчиков. Разумеется, я буду рад вашим предложениям по поводу того, каким должен быть механизм поддержки изображений в HTML. Если у вас появится мысль удачнее моей, поделитесь, пожалуйста. Я знаю, что разнообразие графических форматов делает ситуацию чрезвычайно туманной, но альтернативы не вижу. Можно разве что сказать: «Пусть браузер работает как умеет» — и ждать той поры, когда будет предложено идеальное решение (может быть, когда-нибудь, с помощью MIME-типов).

Эту цитату надо пояснить. Xbm и Xpm — популярные графические форматы в UNIX-системах; Mosaic — один из первых браузеров. Его версия, которая работала в UNIX-системах, называлась X Mosaic. Когда Марк отправлял это письмо на дискуссионный лист в начале 1993 года, он еще не основал компанию Mosaic Communications Corporation, которая впоследствии принесла ему известность, и еще не начал работу над флагманским продуктом будущей компании — браузером Mosaic Netscape (фирма и программа позже были переименованы в Netscape Corporation и Netscape Navigator соответственно).
Говоря о MIME-типах «может быть, когда-нибудь», Марк ссылается на предусмотренный в протоколе HTTP механизм «переговоров о содержимом». Благодаря этому механизму клиентская программа-браузер сообщает серверу (в данном
случае веб-серверу), какие типы ресурсов она умеет обрабатывать (например, image/jpeg), а сервер в ответ может прислать содержимое в удобном для клиента формате. По состоянию на февраль 1993 года программно реализован только самый первый вариант протокола HTTP (1991 год), в котором клиент не мог передать серверу информацию о поддерживаемых типах изображений. Отсюда проблема, с которой столкнулся Марк. Несколько часов спустя Тони Джонсон (Tony Johnson) ответил:

У меня в Midas 2 .0 (программа пока находится во внутреннем пользовании SLAC, но уже готова к открытому релизу) применяется похожее решение. Тег иначе назван, и в нем есть еще один аргумент NAME=" name", но функциональность абсолютно та же, что и у предложенного вами тега IMG. Пример:

<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">

Смысл параметра NAME в том, чтобы позволить браузеру прибегать к помощи набора «встроенных» картинок. Если имя соответствует изображению, которым браузер уже располагает, то вместо того, чтобы доставать картинку из Сети, программа использует готовый графический файл. Кроме того, имя изображения может подсказывать текстовым браузерам, каким символом заместить картинку.
Меня мало волнуют имена тегов и параметров (но если бы мы решили прийти к компромиссу, они приобрели бы большое значение). Столь же маловажен, по-моему, вопрос об аббревиатурах, то есть почему IMG и SRC, а не IMAGE и SOURCE. Мне самому больше по душе ICON — это слово дает понять, что картинка должна быть маленькой, вроде значка. Готов признать,
впрочем, что слово ICON итак уже обременено множеством смыслов .

Midas — это еще один ранний браузер, современник X Mosaic. Он был кросс-платформенным и работал как в UNIX, так и в VMS. Аббревиатура SLAC расшифровывается как Stanford Linear Accelerator Center (Научно-исследовательский центр при Стэнфордском линейном ускорителе (электронов)). Теперь этот центр получил статус национальной лаборатории. Инженеры SLAC запустили первый веб-сервер в США, который фактически был и первым за пределами Европы. В феврале 1993 года SLAC считался долгожителем Сети (работал год и три месяца!) с пятью веб-страницами на сервере.
Вот продолжение письма Тони:

Раз уж мы заговорили о новых тегах, то расскажу о другом аналогичном теге, поддержку которого я намерен реализовать в Midas 2 .0. Его схема такова:

<INCLUDE HREF="...">

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

Под названием HTTP2 здесь фигурирует базовый HTTP в редакции 1992 года. В начале 1993 года значительная его часть не имела программной реализации. Черновой вариант, известный как HTTP2, после некоторой доработки был стандартизован в качестве HTTP 1.0. В стандарт HTTP 1.0 уже включены заголовки-запросы для переговоров о содержимом, то есть то самое «может быть, когда-нибудь» наступило довольно скоро.
Тони так заканчивает свое письмо:

Я рассматривал и следующую альтернативу:

<A HREF="..." INCLUDE>См. фотографию</A>

Не хочется прибавлять новую функциональность тегу <A>. Но такое решение было бы удобно для совместимости с браузерами, которые не понимают параметр INCLUDE. Иными словами, если браузер распознает команду INCLUDE, то он заменит текст ссылки («См. фотографию» в данном случае) картинкой, а более старый или более глупый браузер просто проигнорирует INCLUDE.

Это предложение не было реализовано, хотя идея заместительного текста на случай, если изображение отсутствует, очень привлекательна и не упоминается в предложенной Марком конструкции тега <IMG>. Много лет спустя идея была осуществлена в атрибуте <img alt=" ..." > (после чего все испортил Netscape, который ошибочно отображал текст-заместитель в виде всплывающей подсказки).
Через несколько часов после сообщения Тони ему и Марку ответил Тим Бернерс-Ли (Tim Berners-Lee):

Я полагал, что картинки можно представлять в виде <a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Картинка</a>. Значение ссылочных отношений таково:

EMBED — встроить содержимое в данное место документа для отображения;
PRESENT — отображать содержимое, если исходный документ доступен.

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

Это предложение не было реализовано, но атрибут rel существует до сих пор (см. раздел «Элемент HEAD» главы 3).
Джим Дэвис (Jim Davis) прибавил:

Хорошо бы еще иметь возможность указывать тип содержимого, например, так:

<IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>

Однако я, конечно, надеюсь дожить до того времени, когда тип содержимого будет строго определяться по расширению файла.

Это предложение тоже не было реализовано, хотя позднее Netscape стал поддерживать встраивание произвольных мультимедийных объектов с помощью тега <embed>.
Джей Вебер (Jay C. Weber) написал следующее:

Отображение графики в браузерах — моя давняя мечта. Но неужели для каждого вида мультимедийной информации надо создавать персональный тег? Еще недавно все с радостью ожидали появления механизма MIME-типов. Что же случилось теперь?

Марк Андрессен ответил:

Это не альтернатива предстоящему использованию MIME-типов как стандартного механизма обработки документов. Это простая реализация функциональности, которая нужна независимо от MIME.

Джей Вебер возразил:

Забудем на время о MIME-типах, они отвлекают от сути. Я, собственно, не согласен с вашим подходом к поддержке встроенных изображений, ведь можно ожидать, что на следующей неделе кто-нибудь предложит новый тег <AUD SRC=" file://foobar .com/foo/bar/blargh .snd"> для звуковых файлов. Между тем за использование единого для всех медийных типов способа встраивания пришлось бы платить не такой уж и дорогой монетой.

Опыт свидетельствует, что беспокойство Джея было вполне обоснованным. Прошло, правда, больше недели, но в HTML5 появились теги <video> и <audio>.
В ответ на первое письмо Джея Дейв Рэггет (Dave Raggett) написал:

Совершенно правильно! Собираюсь рассмотреть множество графических и псевдографических типов в связи с механизмом переговоров о формате. Замечание Тима о поддержке активных областей на картинках тоже учту.

В том же 1993 году, но немного позже Дейв опубликовал стандарт HTML+, задуманный им в качестве замены первоначальному HTML. Стандарт не был реализован; на смену HTML пришел ретроспективный HTML 2.0 — формальное описание того аппарата тегов, который на момент принятия стандарта уже широко использовался: «Эта спецификация сводит воедино, уточняет и формально описывает функции из того набора, который приблизительно соответствует возможностям общеупотребительного HTML по состоянию на июнь 1994 года».
Позже на основе спецификации HTML+ Дейв Рэггет создал стандарт HTML 3.0. Нигде, кроме внутренней (используемой W3C в качестве эталона) программы Arena, стандарт HTML 3.0 не был реализован. На смену ему пришел HTML 3.2 — вновь ретроспектива: «Сохраняя полную обратную совместимость с существующим HTML 2.0, стандарт HTML 3.2 добавляет к нему широко распространенные новые функции: таблицы, приложения и обтекание изображений текстом».
Еще позже Дейв выступил в качестве одного из соавторов HTML 4.0, разработал HTML Tidy, принимал участие в подготовке XHTML, XForms, MathML и других современных спецификаций W3C. В далеком 1993 году Марк ответил Дейву так:

Может быть, стоило бы действительно задуматься о графическом процедурном языке общего назначения, возможности которого позволили бы присоединять произвольные гиперссылки к значкам, картинкам, тексту и т. д .? Не известно ли кому-нибудь из подписчиков, как с этим обстоит дело в проекте Intermedia?

Intermedia — это гипертекстовый проект Брауновского университета. Работа над ним велась в 1985–1991 годах. Рабочей средой для Intermedia была операционная система A/UX — UNIX-подобная среда, функционирующая на компьютерах Macintosh первых поколений. Мысль о «графическом процедурном языке общего назначения» впоследствии прижилась. Современные браузеры поддерживают как SVG-графику (декларативную разметку со встроенной возможностью разработки сценариев), так и <canvas> (процедурный интерфейс непосредственного программирования графики). Правда, исторически <canvas> был проприетарным расширением для браузера и рабочая группа WHAT внесла его в спецификацию постфактум.
Билл Дженсен (Bill Janssen) сообщил:

Функциональность, о которой вы говорите, действительно очень ценна. Кроме Intermedia, есть другие системы, в которых она реализована: Andrew и Slate. В основе Andrew лежит система вставок. Каждой вставке присвоен определенный тип: текст, растровое изображение, векторное изображение, анимация, электронное письмо, таблица и др. Реализовано рекурсивное вложение произвольной глубины, то есть вставка любого типа может быть вложена во вставку любого из типов, поддерживающих вложение. Так, например, можно поместить вставку в тексте после любого символа (если мы работаем с текстовым окном), в любой прямоугольной области (если мы работаем с графикой), в любой ячейке (если мы имеем дело с таблицей).

Andrew — сокращенное название системы пользовательского интерфейса Andrew. Ее в те годы все называли Andrew Project.
Тем временем Томас Файн (Thomas Fine) выдвинул альтернативное предложение:

Я думаю так. Работу с изображениями в Сети лучше всего построить на системе MIME-типов. А формат Postscript, для которого наверняка уже существует особый тип, как раз позволяет совмещать текстовую и графическую информацию с большим удобством. «Но в нем ведь не будут работать гипертекстовые ссылки», — скажете вы. Да, это так. Однако мне кажется, что проблему решает технология Display Postscript. Если и нет, то дополнить до этого стандартный Postscript — легкая задача. Определим команду-якорь, которая бы содержала URL и интерпретировала текущий контур как замкнутую область-кнопку. Поскольку в Postscript предусмотрена прорисовка контуров, это позволяет легко делать кнопки произвольной формы.

Display PostScript — технология экранной прорисовки, совместно разработанная Adobe и NeXT.
Это предложение не было реализовано. До сих пор, впрочем, время от времени озвучивается мысль о том, что для улучшения языка HTML надо его просто чем-нибудь заменить.
2 марта 1993 года Тим Бернерс-Ли оставил такой комментарий:

В HTTP2 документам разрешено нести любой MIME-тип, понимаемый клиентской программой, а не только какой-либо один из зарегистрированных. Это оставляет пространство для экспериментов. Думаю, Postscript с поддержкой гипертекста мог бы стать предметом таких экспериментов. Не знаю, достаточно ли функциональности у Display Postscript, но мне известно, что
компания Adobe сейчас активно продвигает свой формат PDF на основе Postscript. В документах этого формата будут работать гиперссылки, но просматривать такие документы можно будет только в проприетарных программах Adobe.
Я полагал, что обобщенный язык якорей (на основе HyTime?) позволит гипертекстовым и мультимедийным (графика/видео) стандартам развиваться независимо, что пойдет на пользу и тем и другим.
Пусть лучше будет тег не IMG, а INCLUDE, который бы ссылался на документы произвольного типа. Или EMBED, если INCLUDE звучит как директива C++ и будут ошибочно думать, что нужен исходный SGML-код, который браузер будет разбирать (мы имеем в виду не это).

HyTime — это одна из ранних гипертекстовых систем документов, основанная на разметке SGML. В обсуждениях стандартов HTML и затем XML в 1990-е годы о ней часто вспоминали.
Предложенный Тимом тег так никогда и не появился, хотя отголоски этой идеи можно наблюдать в тегах <object>, <embed> и <iframe>.
Наконец 12 марта 1993 года Марк Андрессен написал в той же ветви дискуссии:

Вернусь к теме встроенных изображений. Приближается выпуск Mosaic v0 .10, в котором будет оговоренная ранее поддержка растровых изображений форматов GIF и XBM в тексте.
Поддерживать теги INCLUDE/EMBED мы в настоящее время пока не готовы. Вероятно, сейчас придется остановиться на <IMG SRC=" url" > (а не ICON, потому что не всякое изображение, вставленное в текст, можно назвать значком). Пока что встроенные изображения не типизируются явным образом; мы намерены начать поддержку графических типов впоследствии, когда речь зайдет о реализации системы MIME-типов в целом. Используемые нами сейчас алгоритмы чтения изображений определяют формат на лету, так что даже расширение файла не играет никакой роли.