Кратко
- 25 февраля 1993 года Марк Андриссен предложил необязательный элемент
IMGс обязательнымSRC, указывающим bitmap или pixmap, который браузер должен получить и показать в заданном месте документа. - Изображение могло быть частью страницы, не являясь ссылкой. Если автор хотел сделать его кликабельным, элемент
Aмог обернуть изображение и отдельно задать цель перехода. HTML 2.0 сохранил этот принцип и определилALTкак текстовую альтернативу.
Предложение Андриссена было не попыткой изобрести изображение на экране. Оно решало более узкую задачу: как вставить графический ресурс в определённое место HTML-документа, не заставляя его адрес одновременно выполнять роль цели гиперссылки. 25 февраля 1993 года Марк Андриссен написал в список рассылки WWW-TALK и предложил отдельный элемент IMG.
Элемент был необязательным, но требовал SRC="url". Браузер должен был попытаться получить указанный bitmap или pixmap по сети и отобразить его там, где встречалась разметка. Закрывающий тег не требовался. Таким образом, документ мог запросить внешний визуальный ресурс, не объявляя сам этот ресурс ссылкой.
Действие при щелчке задавалось отдельно. Андриссен пояснил, что IMG можно поместить внутрь якоря. Тогда изображение реагировало на активацию подобно ссылочному тексту. Без внешнего якоря IMG только показывал картинку и не определял, куда должен перейти читатель. Автор мог включить изображение в абзац или сделать его видимой частью ссылки.
На следующий день Джим Дэвис спросил, почему атрибут называется SRC, а не HREF, и предложил указывать тип содержимого. Андриссен ответил, что не хочет придавать HREF дополнительное значение: этот атрибут уже задаёт цель якоря. SRC обозначает ресурс, который нужно получить для отображения. В конструкции вроде <A HREF="цель"><IMG SRC="картинка"></A> обе связи можно выразить отдельно.
Это было не просто предпочтение одного имени другому. Одно и то же изображение можно было показать без перехода, связать со страницей пояснений или использовать повторно с разными целями. Изменение адреса перехода не требовало менять адрес изображения. И наоборот, размещение изображения в документе не обязывало отправлять читателя к файлу-источнику.
Однако участники списка обсуждали, не слишком ли узок элемент только для изображений. 1 марта Дэйв Рэггетт предложил рассмотреть более общий механизм для внешних медиа с типами MIME и согласованием форматов. В марте Гвидо ван Россум обсуждал границы INCLUDE и EMBED, в том числе риск рекурсивного включения: один внедрённый документ мог бы включить следующий. Универсальная конструкция охватывала бы больше типов данных, но поднимала вопросы типов, компоновки, вложенности и поведения браузеров, не знающих формат. Архив показывает сам спор, но не указывает одно письмо как окончательное решение всех участников.
Предложение Андриссена оставляло часть работы по совместимости разработчикам браузеров. Он называл XBM и XPM полезными форматами, но считал, что браузеры должны самостоятельно выбирать поддерживаемые типы. Если X Mosaic не мог разобрать формат, он показывал изображение-заполнитель по умолчанию. Андриссен также писал, что функция уже работала внутри X Mosaic и была необходима этому браузеру. Это его сообщение о внутренней реализации; оно не устанавливает дату первого публичного выпуска, число пользователей или причины, по которым другие браузеры приняли элемент.
К 1995 году обсуждение затронуло и то, что увидит читатель, если изображение не удастся обработать. В июньской переписке рабочей группы HTML рассматривались случаи, когда пользовательский агент мог обработать ALT вместо ресурса, указанного в SRC, например из-за технических ограничений или предпочтений пользователя. Участники также различали отсутствие ALT и явно пустое значение. Само наличие такого обсуждения не означало, что авторы страниц предоставляли полезные описания.
В ноябре 1995 года RFC 1866, определивший HTML 2.0, формализовал IMG и атрибуты SRC, ALT, ALIGN и ISMAP. SRC задавал URI графического ресурса, а ALT — текст, который можно было использовать вместо него, если изображение не обрабатывалось. RFC также чётко указывал: изображение IMG само по себе не является якорем. Существенную графику следовало связывать через A, а для необязательной графики подходил IMG. При этом в примере самого RFC IMG помещён внутрь A. Противоречия нет: изображение не создаёт переход самостоятельно, но якорь может сделать его кликабельным содержимым ссылки.
Стандарт показывает и дальнейшее развитие идеи. В 1993 году Андриссен упоминал bitmaps и pixmaps, оставляя поддержку форматов на усмотрение браузеров. RFC 1866 отмечал, что на практике обычно применялись GIF и JPEG. Атрибут CONTENT-TYPE в IMG не появился: элемент называл ресурс, а браузер решал, можно ли отобразить полученный формат. ALT предоставлял запасной вариант, но DTD не делал его обязательным.
История поэтому не сводится к тому, что «веб получил изображения». Предложение сделало изображение отдельно адресуемым ресурсом, который можно разместить в документе, не приравнивая его к гиперссылке. Позднейший стандарт сохранил эту композицию и прямо обозначил границу между отображением и переходом. Источники подтверждают именно эту линию проектирования. Они не доказывают, что один лишь IMG сделал веб популярным, что Mosaic был первым графическим браузером или что все реализации работали одинаково.
Источники
- Марк Андриссен, “proposed new tag: IMG”, 25 февраля 1993 года
- Джим Дэвис и Марк Андриссен о
SRC,HREFи типе содержимого, 26 февраля 1993 года · Ответ Андриссена - Дэйв Рэггетт об общей обработке медиа, 1 марта 1993 года · Гвидо ван Россум о границах включения, 13 марта 1993 года
- Дэниел Коннолли о формулировке
ALT, 1 июня 1995 года · Роберт Лилли об альтернативном тексте, 2 июня 1995 года - RFC 1866, Hypertext Markup Language — 2.0, ноябрь 1995 года
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

