![](https://habrastorage.org/storage2/c87/cde/730/c87cde7304d3c4f51173158cbc07b970.jpg)
Выпал снежок и как-то незаметно пришло праздничное, предновогоднее настроение. Чтобы как-то поддержать праздничный дух, мы решили сделать небольшой сюрприз от издательства и порадовать наших читателей бесплатной электронной книгой Марка Пилгрима «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
. Хорошенько запомните эту информацию, так как она еще пригодится.Большое отступление о том, как появляются стандарты
Откуда взялся тег ? Не думаю, что вы хоть иногда задавались подобным вопросом. Очевидно, кто-то его создал. Такие вещи не берутся ниоткуда. Из всех элементов и атрибутов HTML, которыми вы в разное время пользовались, абсолютно каждый был когда-то кем-то создан. Этот кто-то придумал, как должен работать элемент или атрибут, и письменно сформулировал свои мысли. Такого рода люди, бесспорно, умнее нас с вами, но они тоже обычные люди.
Если стандарт разрабатывался открыто, то можно вернуться в прошлое и увидеть, как рождалась идея того или иного пункта спецификации. Обсуждения ведутся в почтовых рассылках, а их архивы обычно имеют интерфейс поиска. Чтобы ответить на вопрос о теге , я решил немного позаниматься «электронной археологией» и погрузился в толщу времен, когда еще не существовало Консорциума Всемирной паутины (W3C), а все веб-серверы мира можно было пересчитать по пальцам. Речь идет о первых днях Интернета.
25 февраля 1993 года Марк Андрессен (Marc Andreessen) написал:
Предлагаю новый опциональный HTML-тег:
IMG
При нем должен обязательно указываться аргумент SRC=" url". Тег отсылает к файлу растрового изображения (bitmap или pixmap). Браузер будет запрашивать этот файл в Сети, распознавать как изображение и вставлять в текст сообразно месту
тега в коде страницы.
Пример использования:
(Закрывающий тег не требуется.)
Как и любое другое содержимое, этот тег может быть вложен внутрь якоря. Тогда изображение станет чувствительным к активизации, как и обычная текстовая ссылка. Следует предоставить браузерам свободу выбора графических форматов, которые будут в них поддерживаться. Удачным выбором мне представляются, например, 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. Пример:
Смысл параметра NAME в том, чтобы позволить браузеру прибегать к помощи набора «встроенных» картинок . Если имя соответствует изображению, которым браузер уже располагает, то вместо того, чтобы доставать картинку из Сети, программа использует готовый графический файл . Кроме того, имя изображения может подсказывать текстовым браузерам, каким символом заместить картинку .
Меня мало волнуют имена тегов и параметров (но если бы мы решили прийти к компромиссу, они приобрели бы большое значение) . Столь же маловажен, по-моему, вопрос об аббревиатурах, то есть почему IMG и SRC, а не IMAGE и SOURCE . Мне самому больше по душе ICON — это слово дает понять, что картинка должна быть маленькой, вроде значка . Готов признать,
впрочем, что слово ICON итак уже обременено множеством смыслов .
Midas — это еще один ранний браузер, современник X Mosaic. Он был кросс-платформенным и работал как в UNIX, так и в VMS. Аббревиатура SLAC расшифровывается как Stanford Linear Accelerator Center (Научно-исследовательский центр при Стэнфордском линейном ускорителе (электронов)). Теперь этот центр получил статус национальной лаборатории. Инженеры SLAC запустили первый веб-сервер в США, который фактически был и первым за пределами Европы. В феврале 1993 года SLAC считался долгожителем Сети (работал год и три месяца!) с пятью веб-страницами на сервере.
Вот продолжение письма Тони:
Раз уж мы заговорили о новых тегах, то расскажу о другом аналогичном теге, поддержку которого я намерен реализовать в Midas 2 .0. Его схема такова:
В код документа в месте вхождения этого тега должен быть вставлен другой документ, на который ссылается тег . Этот документ может быть чем угодно по типу содержания, но основная задача тега — обеспечить вставку изображений произвольного размера в веб-страницы. Когда будет реализован HTTP2, клиент и сервер смогут дополнительно оговаривать формат вставляемого документа.
Под названием HTTP2 здесь фигурирует базовый HTTP в редакции 1992 года. В начале 1993 года значительная его часть не имела программной реализации. Черновой вариант, известный как HTTP2, после некоторой доработки был стандартизован в качестве HTTP 1.0. В стандарт HTTP 1.0 уже включены заголовки-запросы для переговоров о содержимом, то есть то самое «может быть, когда-нибудь» наступило довольно скоро.
Тони так заканчивает свое письмо:
Я рассматривал и следующую альтернативу:
<A HREF="..." INCLUDE>См. фотографию
Не хочется прибавлять новую функциональность тегу. Но такое решение было бы удобно для совместимости с браузерами, которые не понимают параметр INCLUDE . Иными словами, если браузер распознает команду INCLUDE, то он заменит текст ссылки («См . фотографию» в данном случае) картинкой, а более старый или более глупый браузер просто проигнорирует INCLUDE.
Это предложение не было реализовано, хотя идея заместительного текста на случай, если изображение отсутствует, очень привлекательна и не упоминается в предложенной Марком конструкции тега . Много лет спустя идея была осуществлена в атрибуте (после чего все испортил Netscape, который ошибочно отображал текст-заместитель в виде всплывающей подсказки).
Через несколько часов после сообщения Тони ему и Марку ответил Тим Бернерс-Ли (Tim Berners-Lee):
Я полагал, что картинки можно представлять в видеКартинка
. Значение ссылочных отношений таково:
EMBED — встроить содержимое в данное место документа для отображения;
PRESENT — отображать содержимое, если исходный документ доступен.
Стоит отметить, что возможны разные сочетания атрибутов. Если браузер не поддерживает какой-то один из них, сбоя не будет. Понятно, что для создания таким способом значков, чувствительных к пользовательскому выбору, нужно вложить один якорь в другой. Но, честно говоря, я не хотел бы вводить особый тег.
Это предложение не было реализовано, но атрибут rel существует до сих пор (см. раздел «Элемент HEAD» главы 3).
Джим Дэвис (Jim Davis) прибавил:
Хорошо бы еще иметь возможность указывать тип содержимого, например, так:
Однако я, конечно, надеюсь дожить до того времени, когда тип содержимого будет строго определяться по расширению файла.
Это предложение тоже не было реализовано, хотя позднее Netscape стал поддерживать встраивание произвольных мультимедийных объектов с помощью тега
.
Джей Вебер (Jay C. Weber) написал следующее:
Отображение графики в браузерах — моя давняя мечта . Но неужели для каждого вида мультимедийной информации надо создавать персональный тег? Еще недавно все с радостью ожидали появления механизма MIME-типов . Что же случилось теперь?
Марк Андрессен ответил:
Это не альтернатива предстоящему использованию MIME-типов как стандартного механизма обработки документов . Это простая реализация функциональности, которая нужна независимо от MIME .
Джей Вебер возразил:
Забудем на время о MIME-типах, они отвлекают от сути . Я, собственно, не согласен с вашим подходом к поддержке встроенных изображений, ведь можно ожидать, что на следующей неделе кто-нибудь предложит новый тег для звуковых файлов . Между тем за использование единого для всех медийных типов способа встраивания пришлось бы платить не такой уж и дорогой монетой .
Опыт свидетельствует, что беспокойство Джея было вполне обоснованным. Прошло, правда, больше недели, но в HTML5 появились теги