JavaScript из Netscape 2.0 не умел почти ничего, кроме как открывать и закрывать окна броузера (стр. 198), загружать в них документы, управлять фреймами и взаимодействовать с полями форм (например, проверяя правильность введенных в них значений). Сценарий, встроенный в документ с помощью тега SCRIPT, мог вставлять кусочки HTML-кода в то место документа, в котором расположен сам, но не мог ни считывать содержимое других частей документа, ни, самое главное, изменять текст или графику документа после его загрузки на компьютер пользователя.
В третьей версии броузера Netscape набор объектов, которыми мог манипулировать сценарий, был существенно, хотя и не кардинально расширен. Стали возможными такие трюки, как плавное изменение цвета фона при загрузке страницы или «живые» меню, каждый пункт которых изменяется, когда над ним проводишь мышью (эффект «перекатывания», стр.213). Эти усовершенствования, однако, лишь разбудили аппетит веб–дизайнеров, которых все меньше устраивал произвол авторов языка: почему такой–то атрибут такого–то тега сценарий может менять динамически, а другие атрибуты этого же тега или аналогичный атрибут другого тега — нет?
Недоделанность JavaScript пришлась как нельзя более на руку компании Microsoft, как раз в это время бросившей все усилия на завоевание рынка броузеров. Еще в третьей версии Microsoft Internet Explorer язык сценариев (который фирме пришлось назвать JScript, так как марка JavaScript принадлежала Netscape) отличался от своего конкурента разве что тем, что многочисленные ошибки и упущения в его реализации были расположены в непривычных местах. В четвертой версии, однако, фирма Microsoft решила уйти в отрыв.
Как известно маркетологам, одно из главных условий успеха любой новинки — запоминающееся название. Чтобы не раздражать пользователей путаницей между JScript и JavaScript, фирма Microsoft окрестила комбинацию, включающую расширенный язык сценариев, частичную поддержку CSS2 и несколько мелких усовершенствований, словосочетанием «динамический HTML», — развернув, по своему обыкновению, массированную рекламную кампанию, подающую его как средство от всех без исключения болезней «обычного» HTML. Netscape волей–неволей должна была ответить на вызов и, скрепя сердце, объявила о поддержке динамического HTML в четвертой версии своего броузера, — хотя его возможности имели довольно мало общего с набором технологий Microsoft.
Основную идею динамического HTML можно сформулировать очень просто: полный контроль языка сценариев над всеми без исключения элементами документа, параметрами их оформления и размещения (как подразумеваемыми в HTML, так и задаваемыми с помощью CSS) и даже над самим текстом страницы. Благодаря этому любой элемент HTML-документа сможет двигаться в произвольном направлении, как угодно изменять свое форматирование и буквально переписываться — как в ответ на действия пользователя, так и по собственной инициативе. В сочетании с абсолютным позиционированием элементов средствами CSS (стр. 241) это позволяет реализовать на веб–странице почти полноценный программный интерфейс с выпадающими многоуровневыми меню (стр. 214), перетаскиванием объектов мышью и т. п.
До сих пор, впрочем, динамический HTML особого распространения в Интернете не получил, и для этого есть объективные причины. Главную роль играет, конечно, несовместимость броузеров–конкурентов, из–за которой очень трудно, а в некоторых случаях и невозможно создать одну версию динамической страницы, которая сохраняла бы работоспособность в обоих броузерах. Сказывается также конкуренция со стороны формата Shockwave Flash, в котором можно реализовать не менее интерактивные эффекты, чем в динамическом HTML, который притом полностью застрахован от несовместимостей (существует только один, разработанный самой фирмой Macromedia подключаемый модуль для просмотра Flash–вставок) и имеет стандартную специализированную среду разработки. Конечно, с доступностью информации в неграфических средах (стр. 34) у Flash дела обстоят куда хуже, чем у динамического HTML, но графические дизайнеры, к сожалению, редко задумываются о таких вещах.
Как всегда с опозданием, свое слово сказал и W3C. Разработанный им стандарт «объектной модели документа» (Document Object Model, DOM) подробно описывает взаимодействие встроенного в веб–страницу сценария с элементами документа, перечисляя все возможные действия, свойства и взаимозависимости для объектов, на которые распадается содержимое документа с точки зрения сценария. Пока достаточно близко к этим предписаниям подошел только броузер Microsoft.
Спецификация DOM оперирует достаточно общими принципами и потому не зависит ни от конкретного языка разметки документа, ни от языка сценариев. В то же время стандартизации не избежал и сам JavaScript; его «официальная», в общественном пользовании находящаяся версия называется ECMAScript (стандарт этот был создан не W3C, а европейской промышленной ассоциацией ЕСМА). Интересно следить за тем, как компании, всегда стремившиеся любыми средствами добиться преимущества над конкурентами и по возможности монополизировать свой сектор рынка, начинают уступать инициативу независимым организациям — стандартизаторам (состоящим, впрочем, из представителей тех же самых фирм–конкурентов), постепенно осознавая важность единых и обязательных для всех «правил игры».
Недостатки JavaScript, как это обычно бывает, продолжают его достоинства. Тесная связь с HTML позволяет (по крайней мере, в идеале) свободно манипулировать материалом страницы, но сильно ограничивает репертуар доступных этому языку «общекомпьютерных» функций, которые бы позволили реализовать на веб–странице фрагменты по–настоящему интерактивного интерфейса.
И наоборот, почти никаких ограничений нет у «обычных» компьютерных языков программирования, с помощью которых создается большинство компьютерных приложений (включая, кстати, и сам броузер). Поэтому первой в голову приходит идея включить в состав веб–страницы готовую к выполнению программу точно так же, как к ней подключаются хранящиеся во внешних файлах изображения. В окне броузера этому объекту будет соответствовать прямоугольная область определенных размеров, внутри которой управление выводом на экран и взаимодействие с пользователем полностью возьмет на себя подключенная программа. От обычного, запущенного на том же компьютере приложения такая «встроенная» программа отличалась бы только отсутствием собственного окна и сохранением своего положения относительно других элементов страницы (в частности, рабочую область этой программы можно будет промотать вверх или вниз вместе с прочим содержимым окна броузера).
К сожалению, существует сразу несколько препятствий к реализации этой простой схемы.
• Исполняемый файл программы, скомпилированной для одной компьютерной платформы (например, для Windows 95), не будет работать на другом типе компьютеров (например, на Макинтоше) или в другой операционной системе (например, в DOS). Веб–страница не имеет возможности выяснить, в какую операционную систему она попала на компьютере пользователя, так что выбор нужной версии программы из нескольких имеющихся отпадает. Это ограничение можно обойти, пересылая с сервера не готовый к исполнению двоичный код, а исходный текст программы на языке программирования, с тем чтобы компьютер пользователя самостоятельно превращал его в понятный ему код. Такое решение, однако, имеет свои недостатки: потерю значительной части быстродействия, незастрахованность от ошибок при компиляции и необходимость устанавливать на компьютер наряду с броузером еще и интерпретатор языка программирования (который будет тем объемистее, чем больше возможностей предоставляет данный язык).
• Давать любому желающему возможность выполнять на вашем компьютере свои программы — более чем рискованная затея. В отличие oTJavaScript–сценария, в котором соответствующих средств нет и не может быть в принципе, программа на обычном языке программирования способна заразить вас вирусом, попортить данные на вашем диске или уворовать конфиденциальную информацию.
• Наконец, довольно трудно обеспечить небольшой объем файла с программой, приемлемый для перекачивания по сети. Если графику всегда можно попытаться оптимизировать, уменьшив ее размер за счет некоторой потери качества, то объем файла программы почти не поддается изменению без существенного усечения ее функций.
На данный момент существуют три технологии встраивания программных объектов в документ. Все они так или иначе пытаются справиться с перечисленными ограничениями.
• Технология подключаемых модулей (plug–in modules) подразумевает наличие двух компонентов: общего для всех объектов данного типа модуля, который достаточно перекачать из сети один раз и установить на компьютере пользователя как обычную программу, и подключаемых к HTML-странице объектов. Последние интерпретируются и выводятся на отведенное им место в пределах страницы соответствующим модулем, запуск которого (как правило, в фоновом режиме, т. е. без создания собственного окна) берет на себя броузер.
