Первое описание HTML было выполнено в строгом соответствии с этой идеей - весь язык был описан в терминах SGML. Читая этот документ, приходилось с трудом продираться через SGML-разметку.

С начала осуществления проекта Тима Бернерса Ли "Гипертекст для CERN" минуло семь лет. Что же мы видим? Web-сообщество снова возвращается к истокам!

При рождении Web многое делалось руками энтузиастов-практиков. Академический стиль описания Web-технологии не совсем соответствовал прагматичному характеру Internet. Простой пример HTML-документа, который когда-то выставил на своем сервере Национальный центр по приложениям для суперкомпьютеров (NCSA), гораздо больше способствовал популярности Web, чем первая спецификация языка. Многие авторы Web-страниц даже не подозревали о связи HTML и SGML. С первых дней наметилась тенденция к упрощению документов. Стандарт HTML 2.0 впоследствии эти упрощения закрепил.

К этому времени эпоха энтузиастов от Web постепенно закончилась, и началось широкое коммерческое использование Web. Компьютерные фирмы вступили в борьбу за новые технологии и стали активно расширять возможности языка. Научная общественность предприняла отчаянную попытку отстоять свои позиции в борьбе за Web, разработав стандарт HTML++, но деньги решили все, и формулы, которые составляли изюминку последнего, так и не прижились в качестве общеупотребительного стандарта.

Netscape и Microsoft, опережая друг друга, пытались внедрить свои предложения, добавляя реализацию новых тэгов в свои браузеры, не дожидаясь появления новых стандартов, утвержденных консорциумом W3C. Век любителей приближался к завершению. Еще держался на плаву проект Mosaic, но уже было ясно, что он умрет точно так же, как до него ушли на заслуженный отдых Chimera, Cello и прочие браузеры, разработанные в стенах университетов.

Инициатива прочно и надолго перешла к фирмам - лидерам индустрии программ. Проекты консорциума W3C приобрели чисто демонстрационный характер, так как и Arena, и последовавшие за ней программы просмотра не могли и не смогут в будущем составить конкуренцию продуктам Netscape и Microsoft. Исключением из правил является Lynx - алфавитно-цифровой клиент, который постоянно держится в первой десятке программ просмотра Web. Видимо, существует достаточно большое количество любителей этого типа интерфейса, предпочитающих иметь дело со скромными, без графических изысков текстовыми документами.

Возвращение к истокам

В 1997 году страсти вокруг SGML разгорелись с новой силой. Практически все производители программ для Web вновь обратились к первоначальной идее Тима Бернерса Ли и даже решили ее несколько развить. Проявилось это желание в том, что после долгого пребывания в роли так и не использованного стандарта Netscape и Microsoft реализовали в четвертых версиях своих браузеров поддержку каскадных описаний стилей (Cascading Style Sheets), а общественность стала широко обсуждать возможность применения в качестве языка разметки XML (eXtended Markup Language), или, как его еще называют, динамического HTML - нового упрощения стандарта SGML.

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

Чтобы разобраться во всех этих вопросах, вспомним события 1992 года - принятие стандарта HTML 2.0. К тому моменту стало ясно, что идея, положенная в основу языка, не нашла широкой поддержки в массах. Язык стремительно упрощался в части своего синтаксиса. Но, как говорится, "из песни слова не выкинешь". HTML - это только часть технологии Web. Пусть наиболее заметная пользователю, но только часть.

Примерно в то же время начинает изменяться технология серверов протокола HTTP. Все больше HTML-страниц верстается не руками, а генерируется программами "на лету", по запросу конкретного клиента. Это был период технологического роста Web-технологии. Через два года удалось затмить популярность Gopher и стать основным информационным ресурсом Сети.

Развитие средств разработки серверных приложений подтолкнуло разработчиков технологических средств Web к идее создания языков программирования, которые стали бы общими как для сервера, так и для клиента. В конце 1994 года в недрах Netscape рождается идея LiveWare. Но тут в спор вклинилась корпорация Sun со своим новым языком. Компания по рекламе Java оказалась столь мощной и масштабной, что остальные компании предпочли сесть на хвост Sun и таким образом продвигать свои решения без особых материальных затрат.

С одной стороны, нельзя сказать, что сама идея мобильного программирования была в это время новой для World Wide Web. В списке консорциума W3C существовало порядка пяти различных предложений, но все их нужно было реализовывать, а у Sun уже был пусть еще сырой, но уже готовый к употреблению язык. Выполнив продвижение этого средства на рынок в стиле а-ля Microsoft, Sun ввело в употребление термин "intranet" для обозначения корпоративных информационных систем, построенных на основе Web-технологии. Последние, кстати, в то время с успехом реализовывались и без Java. Однако, в "яванском кофе" была одна очень важная изюминка - язык опирался на объекты. Последнее обстоятельство было чрезвычайно важным с точки зрения дальнейшего технологического развития Web.

А что же LiveWare? Он сменил имя и превратился JavaScript. Несмотря на созвучие в именах, общего с творением Sun у этого языка было только то, что он опирался на объектную модель. Сами объекты в нем были совершенно иные.

Объекты и контейнеры

К этому времени в документации по HTML происходит подмена терминов. Вместо традиционного "элемент" все чаще начинают употреблять термин "контейнер". Такая подстановка, конечно, не случайна. Контейнеры - это готовые объекты, содержание которых можно менять в отличие от плоских и невыразительных элементов.

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

Такой поворот событий совершенно естествен для Internet. Вспомним хотя бы электронную почту, в которой стандарт MIME именно в этом ключе расширил возможности спецификации RFC822. Двигаясь дальше в том же направлении, следовало ожидать появления аналогичных возможностей в Web.

Они не замедлили о себе заявить. Если фреймы позволяли создавать документы типа multipart/external стандарта MIME, то новые конструкции типа LAYER обеспечили реализацию смешения типов multipart/alternative и multipart/mixed. Конечно, такие параллели могут быть несколько неточными, но общую тенденцию развития они отражают.

Манипулировать контейнерами гораздо проще и удобнее. Именно эта идея легла в основу JavaScript. Такое решение хорошо ложилось и на концепцию кода программы-навигатора, так как в конечном итоге под каждый контейнер так или иначе приходилось отводить место. Более того, новые объекты стало возможным создавать непосредственно в программе. Действительно, какая разница, когда будет создан объект - в момент загрузки или на этапе выполнения программы.

Совершенно естественным продолжением этой концепции явилось появление массивов встроенных объектов. Последние позволили легко реализовать мультипликацию и динамическое изменение ссылок. Для этого требовался лишь контейнер, который позволял бы динамически менять часть содержания документа. Так появился контейнер LAYER. Кроме того, процесс загрузки этого нового содержания удалось скрыть от пользователя.

В связи с этим стоит отметить еще один любопытный феномен. Качество отображения документов все ближе подбирается к типографскому качеству. Собственно, разработчики программных средств и не скрывают, что это является их целью. При этом идея бесконечного нелинейного текста, каковым изначально представлялось содержимое World Wide Web, постепенно отходит на второй план. Более подходящей для современной реализации оказалась идея, заложенная в исследовательских работах компании Xerox и затем перенесенная в интерфейс компьютеров Apple. Она состоит в том, что вся информация отображается в рабочем поле экрана на карточках ограниченного размера. При этом желательно, чтобы сами информационные фрагменты были по размерам не больше карточки, на которой они отображаются. Если почитать рекомендации по разработке "хороших" Web-страниц, то именно к этому требованию сводятся все рекомендации по части размера страницы. На самом деле идея многомерного информационного объекта приживается не очень хорошо, вспомним хотя бы VRML и другие трехмерные технологии.

Возвратимся, однако, к контейнерам HTML и зафиксируем тот факт, что в конечном итоге современная Web-технология манипулирует некоторыми объектами, которые, с одной стороны, имеют свойства, а с другой - над каждым их них можно выполнить определенные преобразования. Этими объектами как раз и являются контейнеры языка.

Свойства контейнеров

Раз существуют обобщенные свойства, то, следовательно, их можно единообразно определять. При этом свойства разных контейнеров могут принимать различные значения. К сожалению, эта простая мысль в течение долгого времени не находила отражения в реализации конструкций языка. Наблюдался застой: механизм определения свойств контейнеров (каскадные описатели стилей) был придуман давным-давно, а вот до его реализаций в коммерческих браузерах дело как-то не доходило. В результате во всем документе использовались одни и те же шрифты. Что самое неприятное, автор документа не мог даже предположить, как его творение будет выглядеть на экране чужого компьютера. Проблему компоновки отчасти решали таблицы. Чтобы они лучше выполняли эти функции, в их описания добавили атрибуты высоты и ширины строк, столбцов и ячеек, причем значения их могли быть как абсолютными, так и относительными. Однако добиться абсолютно идентичного отображения или хотя бы компоновки было нельзя. Любопытно, что даже опытные дизайнеры не могли учесть всех нюансов. Известно, например, что Macintosh может иметь экран, у которого высота больше, чем ширина, при этом вид редактируемой страницы максимально приближается к виду машинописного листа. При компоновке этот факт следует учитывать. Общие рекомендации применительно к данному случаю выглядят так: информационный фрагмент должен помещаться в квадрат 400х400 пикселов. Если посмотреть большинство наших страниц, то они явно вылезают за эти ограничения. Можно понять замысел компоновки, если они все же помещаются в пределы 640х480, но вот размеры 650х400 выглядят несколько странными.

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

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

От описания свойств контейнеров к новым контейнерам

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

Именно эту идею и стараются реализовать авторы XML. Но для описания новых контейнеров нужен язык. И вот тут-то и вспомнили о старом добром SGML. Идея Тима Бернерса Ли снова стала актуальной для широких масс Internet. Web-мастерам вновь хотят предоставить возможность программировать документы. Разработчики Web-страниц однажды уже отвергли это предложение и упростили спецификацию языка. Теперь мы наблюдаем новую попытку его внедрения. Шансы на успех сейчас выше, чем семь лет назад. До 80% воспроизводимых браузерами документов являются сегодня продуктами генерации. В оставшихся 20% большую часть составляют страницы со встроенными фрагментами-скриптами.

Квалификация авторов постоянно растет. Уже можно говорить о стилях дизайна Web-страниц. Если проводить параллели с модной одеждой, то можно выделить классику (стандартные скромные, но строгие средства разметки), аскетический стиль (HTML 2.0), модерн (использование современных средств разметки вплоть до Java при продуманной, но скромной компоновке), авангард (кричащие ультрасовременные страницы с невероятными технологическими решениями), ретро (страницы с применением последних средств управления стилем и формой отображения, которые не позволяют пользователю, которого в данном контексте лучше назвать наблюдателем, изменить при помощи настроек браузера вид и форму отображаемой информации, стилизованной под HTML 2.0) и сюр (характеризуется неожиданным смешением стилей).

В российской части Web все стилистические изыски появляются практически одновременно с возникновением их на Западе, однако есть и существенные отличия. Если западные страницы, кроме эстетики, просто дышат высокой технологичностью, под которой понимают высокую степень воспроизводства решений, то отечественные разработки - это работы Левшей, хорошие, но единичные. Время индустрии создания информационных материалов для Web, которая существует в остальном мире, у нас в стране только-только начинается. Само интересное еще впереди.


Павел Храмцов - руководитель группы РНЦ "Курчатовский Институт". С ним можно связаться по электронной почте paul@kiae.su.

Поделитесь материалом с коллегами и друзьями