Xiper

Длинное отступление о том, как создавались стандарты

Автор: Евгений Рыжков и Татьяна Головко Дата публикации:
Последнее обновление:

Откуда взялся элемент <img>? Не думаю, что ты часто задаешь себе такой вопрос. Очевидно, кто-то его придумал. Такие вещи не появляются просто сами по себе. Каждый тег, каждый атрибут и CSS-правило — все это кто-то когда-то придумал и решил, как оно должно работать. Это были люди, а люди, как известно, не боги, они не безупречны. Это просто люди. Конечно, умные люди. Но, все же, просто люди.

Один из огромных плюсов открытых стандартов — это тот факт, что можно оглянуться назад и найти ответы на такие вопросы. Подобные обсуждения обычно ведутся перепиской по электронной почте, а по окончанию все архивируется. Эти архивы доступны общественности. Я решил попробовать найти ответ, откуда появился <img>. Мне пришлось вернуться во времена, когда не было W3C, во времена зарождения Интернет, когда количество серверов можно было сосчитать на пальцах обеих рук… а может даже одной.

Марк Андрессен написал:

Я хотел бы предложить новый HTML тег:
IMG
Обязательный аргумент SRC="url".
Это имя графического файла, который браузер должен будет загрузить по сети и отобразить в месте расположения тега.
Вот пример:
<IMG SRC="">
(закрывать не нужно, т.к. это автономный тег)

Этот тег может быть включен в ссылку. При клике по такому изображению, будет происходить переход по ссылке, точно так же, как и при клике на текстовую ссылку. Браузеры должны обеспечить гибкую поддержку графических форматов. Например, можно поддерживать Xbm и Xpm. Если браузер не может отобразить данный формат, пусть отображает, как сможет (в X Mosaic взамен появится растровое изображение принятое по умолчанию).

Это необходимая функциональность для X Mosaic; у нас уже есть такая разработка, по крайней мере, мы можем ее использовать. Я всегда готов подискутировать о том, как все это должно выглядеть в HTML и если у кого-то будут идеи получше, пожалуйста, дайте мне знать. Мое предложение в отношении растровых форматов немного расплывчато, но я пока не вижу ничего лучше, чем просто сказать : «пусть отображает, как сможет» и ждать пока появится лучшее решение (MIME, когда-нибудь, наверное).

Эта цитата нуждается в некоторых пояснениях. Xbm и Xpm были популярными графическими форматами в Unix системах.

"Mosaic" был одним из первых веб-браузеров (X Mosaic — это версия для Unix систем). Когда Марк писал это сообщение, им еще не была основана компания, которая сделало его знаменитым — Mosaic Communications Corporation. Так же он еще не начал работу над флагманом этой компании — продуктом Mosaic Netscape (возможно эти названия тебе более знакомы как Netscape Corporation и Netscape Navigator).

«MIME, когда-нибудь, наверное» в письме является ссылкой на ветку обсуждения HTTP, где предлагается, чтобы клиент (веб-браузер) сообщал серверу какие типы данных он поддерживает (например, image/jpeg) чтобы сервер мог вернуть данные в предпочтительных форматах. HTTP разработанный в 1991 не был способен передавать данные о поддерживаемых форматах. Поэтому у Марка с этим были трудности.

Через несколько часов Тони Джонсон ответил:

Мне кажется, что это очень схоже с Midas 2.0 (он сейчас используется в СЛУЦ). Основное отличие — это отсутствие аргумента NAME="name". А в целом функциональность идентична с предложенной Вами.
<ICON name="NoEntry" href="">

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

Я не очень заботился о придумывании названий параметров и тега, но было бы разумно, если бы мы использовали одни и те же слова. Я не думал о сокращениях, но почему бы не использовать IMAGE и SOURCE. Мне больше нравится ICON, т.к. оно подразумевает, что такое изображение будет меньше чем IMAGE. Но возможно ICON – это будет перегруженное слово.

Midas это другой ранний веб-браузер, современник X Mosaic. Он был кроссплатформенным и мог работать как на Unix так и на VMS. «СЛУЦ» — имеется в виду Стэнфордский линейный ускорительный центр (теперь Национальная ускорительная лаборатория), на базе которого был расположен первый web-сервер в Соединенных Штатах (фактически, первый web-сервер за пределами Европы). Когда Тони писал это сообщение, СЛУЦ был старожилом Всемирной паутины: на его сервере уже целый 441 день размещалось аж пять страниц.

Тони продолжал:

Раз уж мы заговорили о новых тегах, у меня есть другой, чем-то похожий тег, который я хотел бы, чтобы Midas 2.0 поддерживал. В принципе, это выглядит так:
<INCLUDE HREF="…">

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

"HTTP2" — это ссылка на документ «Основы HTTP, определенные в 1992 году», на момент диалога, в начале 1993 года, в основном не законченный. Проект, известный как "HTTP2" развивался и, в конце концов, вылился в стандарт HTTP 1.0. Этот стандарт включил в повестку переговоров заголовки запросов, уже упомянутые как «MIME, когда-нибудь, наверное».

Продолжает Тони:

Альтернатива, которую я рассматривал, выглядела так:
<A HREF="..." INCLUDE>Показать фото</A>

Мне не очень нравится добавлять новые функциональные возможности тегу a, но тут идея заключается в поддержке совместимости с браузерами, которые не поймут параметр INCLUDE. Смысл в том, что браузеры понимающие INCLUDE заменят анкорный текст (в данном случае «Показать фото») на подсоединяемый документ (изображение), а более старые или тупые браузеры просто проигнорируют INCLUDE.

Это предложение так и не было реализовано, хотя идея предоставить альтернативный текст, если картинка недоступна, очень важна. И в первоначальном предложении тега <img> у Марка она отсутствовала. Много лет спустя эта идея проявилась, как атрибут alt тега <img>. Кстати, Netscape совершенно ошибочно интерпретировал этот атрибут, как всплывающую подсказку.

Через несколько часов после того, как Тони отправил свое сообщение, ему ответил Тим Бернерс-Ли:

Я представляю себе это так. Рисунки будут представлены как
<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Рисунок</a>

где значения атрибута REL расшифровываются как:
EMBED — если предоставлено, то вставить сюда.
PRESENT — предоставить каждый раз, когда предоставляется исходный документ.

Учтите, что можно составлять различные комбинации параметров, и если браузер не поддерживает какую либо комбинацию, он не должен прерывать интерпретацию страницы.

Я рассматриваю это как метод для помещения картинки внутрь ссылки. Хм... Но я не хочу, чтобы для этого был специальный тег.

В таком виде, это предложение никогда не было реализовано. Но атрибут rel, в конце концов, появился.

Джим Девис добавляет:

Если бы был способ указать тип содержимого, было бы замечательно. Например:
<IMG HREF="" CONTENT-TYPE=audio/basic>

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

Это предложение не было реализовано, но Netscape, позднее, добавил возможность вставки медиа-объектов с помощью тега embed.

Джей С. Вебер спрашивает:

Хотя картинки, среди моего списка пожеланий к браузерам находятся на первой позиции, я все же не думаю, что мы должны добавлять медиа возможности в час по чайной ложке. Что случилось с энтузиазмом по поводу использования механизма MIME?

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

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

Джей С. Вебер отвечает:

Давайте пока забудем про MIME, раз это было не по теме вопроса. Мое возражение относится к дисскусии «как мы собираемся поддерживать встроенные изображения», а не к дискуссии «как мы собираемся поддерживать внедрение медиа объектов»

А иначе, скажем, через неделю, кто-нибудь предложит, например, новый тег: <AUD SRC=""> для аудио.

Это сходные моменты, там не должно быть существенных различий.

Только теперь видно, что предположения Джея были обоснованы. Прошло, конечно, куда больше недели, но в результате мы все-таки имеем HTML5-теги <video> и <audio>.

Отвечая на исходное сообщение Джея, Дэйв Рэгетт сказал:

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

Намного позднее, в 1993 году, Дейв Рэгетт предложил HTML+, как дальнейшее развитие стандарта HTML. Предложение не прошло, а вскоре появился HTML 2.0. Он был ретроспективным, т.е. в основном формализовал общепринятые особенности: «Эта спецификация объединяет, разъясняет и формализует набор функций, которые примерно соответствуют общепринятым возможностям HTML на июнь 1994 года».

Позднее Дейв написал HTML 3.0, основанный на его предыдущем проекте HTML+. Находясь вне консорциума W3C, HTML 3.0 не был реализован. Вместо него появился HTML 3.2, который так же являлся ретроспективным: «HTML 3.2 добавляет широко используемую функциональность, такую как таблицы, апплеты и обтекание текстом изображений, обеспечивая при этом полную обратную совместимость с существующим стандартом HTML 2.0 ».

Дейв позже стал соавтором HTML 4.0, разработчиком HTML Tidy и помогал в разработке XHTML, XForms, MathML, и других современных спецификаций W3C.

Но вернемся в 1993 году. Марк отвечает Дейву:

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

Intermedia представлял собой проект гипертекста Брауновского университета. Он разрабатывался с 1985 по 1991 год для A/UX, Unix-подобной операционной системы ранних Макинтошей.

Идея процедурного общецелевого языка графики в конце концов набрала популярность. Современные браузеры поддерживают SVG (декларативную разметку со встроенными скриптами) и <canvas> (процедурный графический API).

Отвечает Билл Янссен:

Другие системы в которых можно посмотреть на эти понятия это Andrew и Slate. Andrew построен на базе элементов insets, каждый из которых может иметь различные типы, такие как текст, растровое изображение, рисунок, анимация, сообщения, электронные таблицы и прочее. Поддерживается понятие произвольной рекурсивной вложенности одних элементов в другие. Например, вставку можно сделать в любой точке текста, или, допустим, вставить прямоугольную область рисунка в ячейку таблицы.

Под "Andrew" тут имеется в виду Система пользовательского интерфейса Andrew, в то время известная просто как «проект Andrew».

Между тем Томас Файн высказывал другую идею:

По-моему, лучший способ реализовать изображения в WWW — это использование MIME. Я уверен, что PostScript уже поддерживает подтипы в MIME и это позволяет замечательно перемежать текст и графику.

Скажете, это не будет кликабильно? Да, вы правы. Но, я думаю, ответ уже есть — это Display PostScript. Можно определить якорную команду, которая указывает URL и использует текущий путь, как замкнутый регион для кнопки. Поскольку PostScript замечательно работает с путями, это позволяет легко создавать произвольные кнопки.

Display PostScript являлся технологией экранного рендеринга от Adobe и NeXT.

Это предложение не было реализовано, но идея, что лучший способ исправить HTML — это заменить его чем-нибудь другим, время от времени снова возникает.

2 марта 1993 года. Комментарий Тима Бернерса-Ли:

HTTP2 позволяет документу содержать не только зарегистрированные MIME-типы, но и любой тип, про который пользователь сообщает, что он может с ним работать. Таким образом, можно экспериментировать. Да, я думаю, что есть аргументы за использование PostScript для гипертекста. Я не знаю Display PostScript в достаточной мере. Но я знаю, что Adobe пытаются создавать свои собственные PostScript на основе "PDF", в которых будут ссылки.

Я считаю, что общий язык с использованием гиперссылок (возможно на основе HyTime) позволит гипертексту и стандартам видео/графики развиваться отдельно, что будет выгодно и первым и вторым.

Пусть тег IMG будет INCLUD'ом, и пусть он включает возможность обращаться к документам произвольного типа. Или EMBED, если INCLUDE звучит как в С++, и люди будут ожидать, обеспечения включения исходного кода SGML, который будет обрабатываться онлайн, то есть создастся путаница.

HyTime являлся ранней, основанной на SGML, системой для создания гипертекстовых документов. Он часто и много обсуждался во многих дискуссиях, посвященных HTML, и, позже, XML.

Предложение Тима про тег <include> не было реализовано, но ты можешь заметить его отголоски в тегах object, embed, и iframe.

Наконец, 12 марта 1993, Марк Андрессен снова пишет:

Опять вернулся к встроенным потокам изображений… Я подошел вплотную к релизу Mosaic v0.10 который будет поддерживать встроенные GIF и XBM изображения, а так же растровые изображения, как уже упоминалось ранее.

Так что мы не готовы поддерживать INCLUDE/EMBED.

Скорее всего это все-таки будет <IMG SRC="url"> (не ICON, так как не все встроенные изображения по смыслу будут значками). Пока для встроенных изображений не будет явно задаваться тип. Далее, мы планируем поддержку content-type, наряду с общим внедрением MIME. Фактически, при чтении изображения будет применяться определения формата на лету, так что расширение файла уже не будет играть существенной роли.

Куда дальше