Это браузер, который все любят ненавидеть — иногда это оправданно. То, что когда-то было самым инновационным браузером, стало бельмом на глазу для всех разработчиков фронт-энда. Среди суматохи и жалоб, которые современные разработчики бросают в Internet Explorer, часто не слышно, как Microsoft изменила лицо не только фронтальной разработки, но и веб-разработки в целом.
Падение IE — не редкая история; на самом деле, это несколько та же история, что и в Netscape. Компания, стоящая за ведущим браузером, становится самодовольной, браузер застаивается, и появляется новый чемпион. Это повторяющийся цикл, с которым Мозилла снова сталкивается в некоторой степени (но это уже другая история в другой раз).
Влияние IE4 на DOM
До браузеров версии 4 JavaScript в основном использовался для простой обработки данных (проверка формы). Таким образом, веб-страницы были в основном статичными. Хотя страница может динамически генерироваться серверными приложениями, страница не может взаимодействовать с пользователем. Это ограничение существовало из-за неадекватной в браузере объектной модели документов (DOM), которая является интерфейсом прикладного программирования (API), который используют разработчики JavaScript для доступа и управления отдельными элементами на странице. DOM, существовавший до браузеров версии 4, часто называют DOM Level 0. Реализации DOM Level 0 позволяют разработчикам получать доступ к элементам <form/> , <a/> и <img/> , но это все.
«Microsoft возвращает Internet Explorer в нормальное русло».
Netscape Navigator 4
Лишь в середине 1997 года Netscape выпустила Navigator 4 (NS4), когда DOM браузера позволил веб-разработчикам изменять страницы с помощью JavaScript. Техника манипулирования элементами с помощью JavaScript и DOM получила название Dynamic HTML (DHTML). DHTML в NS4, безусловно, был шагом вперед, но его запатентованная и плохо спроектированная основанная на слоях DOM и ограниченная каскадная таблица стилей (CSS) поддерживают разработчиков в ограниченных возможностях.
Доступ к элементам
Netscape не реализовал полную объектную модель. Помимо функциональности DOM Level 0, единственные элементы, к которым мог иметь доступ разработчик, были абсолютно позиционированные элементы, элементы <layer/> элементы <ilayer/> (последние два элемента были де-факто позиционированы). Каждый из этих типов элементов был представлен объектом Layer в DOM NS4. Netscape разработал объекты Layer чтобы они были очень похожи на объекты кадра (и, следовательно, окна). Каждый объект Layer имел свойство document , которое в основном было другим HTML-документом. Как и фреймы, объект Layer может быть вложен в другой объект Layer , что делает код для доступа к этим слоям чрезвычайно многословным, как показано ниже:
|
1
2
3
|
var myLayer1 = document.layers[«myLayerId»].document.layers[«mySecondLayerId»];
// or
var myLayer2 = document.myLayerId.document.mySecondLayerId;
|
Эти две строки кода выполняют одно и то же: они получают доступ к объекту Layer с id mySecondLayerId который вложен в слой с id myLayerId . Да, разработчикам пришлось пройтись по слою «дерево», чтобы получить доступ к вложенным слоям.
Динамический контент
DOM в NS4 не позволяла создавать, вставлять, перемещать и удалять объекты DOM, но поскольку каждый слой отображал объект document , разработчик мог динамически изменять содержимое слоя, используя write() , load() и close() методы. Хотя это дает некоторую дополнительную мощность модели слоя, оно ограничивает разработчиков в том, как они могут динамически обновлять страницу. Новый контент должен быть записан или загружен в слой, эффективно удаляя существующий контент слоя. Излишне говорить, что большинство разработчиков избегали манипулирования контентом и вместо этого сосредоточились на изменении стиля слоя.
Изменение стиля
Веб-разработка с использованием NS4 DOM была болезненной и разочаровывающей.
Но стиль в DOM NS4 был забавным. Хотя браузер в некоторой степени поддерживал CSS, объекты Layer не предоставляли разработчикам API-интерфейс для прямого доступа к атрибуту style слоя, например, к объекту современного style . Вместо этого объекты Layer предоставляют очень ограниченный набор свойств, которые изменяют положение слоя, видимость, обрезку и цвет / изображение фона — ничего больше, и значение, которое принимали эти свойства, также было довольно ограниченным. Например, свойства позиционирования и отсечения принимают только числовые значения; разработчик не может указать единицу измерения (например, px, em, pt и т. д.). Ниже приведен пример такого кода:
|
1
2
|
var myLayer = document.myLayerId.document.mySubLayerId;
myLayer.top = 10;
|
Излишне говорить, что веб-разработка с использованием NS4 DOM была болезненной и разочаровывающей. Чрезвычайно ограниченные возможности DHTML в NS4 проистекают из ограничений движка рендеринга NS4 (он не может переформатировать страницу). Но зачем тратить столько времени на DOM Netscape, особенно в статье, которая должна быть посвящена IE? Если бы Netscape выиграл войну браузеров, сегодняшняя DOM была бы эволюционным шагом по сравнению с DOM, представленной Netscape в NS4. В то время как сегодняшний DOM является стандартом, выдвигаемым W3C (а некоторые идеи Netscape реализованы в сегодняшнем стандарте), на сегодняшний DOM сильно влияет DOM IE4.
IE4 DOM
Всего через несколько месяцев после выхода Netscape Navigator 4 Microsoft выпустила четвертую версию IE. Он также включал поддержку DHTML, но реализация Microsoft значительно отличалась и превосходила NS4 . IE4 может похвастаться гораздо лучшей поддержкой CSS и более полной объектной моделью для доступа и управления элементами и контентом на странице. Эффект DOM IE4 был далеко идущим; На самом деле, разработчик может найти много общего между DOM в IE4 и стандартным DOM.
Доступ к элементам
«Microsoft изменила лицо не только фронт-энда, но и веб-разработки в целом …»
Дизайнеры IE4 хотели превратить браузер в платформу для веб-приложений. Таким образом, они подошли к API IE4 как к операционной системе — предоставили почти полную объектную модель, которая представляла каждый элемент (и атрибуты элемента) как объект, к которому можно было получить доступ с помощью языка сценариев (IE4 поддерживал как JavaScript, так и VBScript).
В DOM IE4 основным средством доступа к определенному элементу на странице была проприетарная коллекция all[] , которая содержала каждый элемент в документе. Разработчики могут получить доступ к элементам с помощью числового индекса или путем указания id или name элемента, например:
|
1
2
3
|
var myElement1 = document.all[«myElementId»];
// or
var myElement2 = document.all.myElementId;
|
Используя этот код, разработчики могут получить доступ к объекту элемента с идентификатором myElementId независимо от того, где он находится на странице. Это резко контрастирует с моделью слоев Netscape, в которой разработчики могут получить доступ к слоям только через иерархию слоев. Функциональность document.all["elementId"] превратилась в стандартный метод document.getElementById() . Но это был не единственный способ, которым разработчик мог получить доступ к элементам; Можно пройтись по дереву DOM и прикоснуться к каждому элементу с parentElement свойства children[] collection и parentElement — предвестников стандартных childNodes[] и parentNode .
В дополнение к загрузке элементов в виде объектов, DOM IE4 представлял атрибуты элемента в качестве свойств объекта элемента. Например, свойства id , name и style отображаются непосредственно в атрибуты id , name и style элемента соответственно. Этот дизайн стал стандартным.
Динамический контент
Microsoft изобрела свойство
innerHTML.
Как и Netscape, Microsoft не предоставила полноценный API для динамического добавления, перемещения и удаления узлов с помощью JavaScript. Однако они изобрели свойство innerHTML для получения или установки содержимого элемента. В отличие от методов write() и load() объекта Layer Netscape, свойство innerHTML не было решением «все или ничего» для изменения содержимого элемента; разработчик может использовать innerHTML для полного удаления, замены или добавления содержимого элемента. Например, следующий код получает содержимое элемента и модифицирует его:
|
1
2
3
4
|
var el = document.all.myElementId,
html = el.innerHTML;
el.innerHTML = html + «Hello, innerHTML»;
|
На сегодняшний день свойство innerHTML является краеугольным камнем DHTML. Это эффективное средство для добавления большого количества контента к элементу. Несмотря на то, что он никогда официально не был включен ни в один стандарт DOM, каждый крупный браузер реализует свойство innerHTML .
Модифицирующий стиль
Microsoft изобрела несколько инструментов и конструкций, которые превратились в части стандартного DOM, но работа, которую они проделали с API стиля IE4, стала стандартной с очень небольшими изменениями. Ключом к изменению стиля элемента в IE4 было свойство
style, то же свойство (и синтаксис), которое используется разработчиками сегодня.
DHTML навсегда изменил веб-разработку. Однако именно DOM IE4 продвинул технологию (и веб-разработку), оказав основное влияние на спецификации DOM Level 1 и 2 W3C. IE4 произвел революцию в веб-разработке в 1997 году, и IE сделает это снова через несколько лет.
IE революционизирует Ajax
Аякс распахнул двери для веб-разработки.
До того, как Ajax был Ajax, он назывался удаленными сценариями, и разработчики, использующие мощь удаленных сценариев, использовали скрытые фреймы и фреймы для связи клиент-сервер. Скрытый (i) фрейм обычно содержал форму, которая была динамически заполнена и отправлена через JavaScript. Ответом сервера будет другой HTML-документ, содержащий JavaScript, который уведомит главную страницу о том, что данные получены и готовы к использованию. Это было грубо, но это сработало.
Однако была альтернатива: малоизвестный камень, похороненный в библиотеке Microsoft MSXML 2.0. IE5, выпущенный в марте 1999 года, включал MSXML 2.0, и разработчики нашли компонент под названием XMLHttp (реальное имя интерфейса было IXMLHTTPRequest ). Его название вводит в заблуждение, поскольку объект XMLHttp больше похож на простой HTTP-клиент, чем на что-либо еще. Разработчики могли не только отправлять запросы с объектом, но и отслеживать состояние запросов и получать ответ сервера.
Естественно, XMLHttp начал заменять метод скрытого (i) фрейма для связи клиент-сервер. Пару лет спустя Mozilla создала свой собственный объект, смоделированный по XMLHttp Microsoft, и назвал его XMLHttpRequest . Apple последовала их примеру со своим объектом XMLHttpRequest в 2004 году, а Opera реализовала этот объект в 2005 году.
Несмотря на растущий интерес, популярность
XMLHttp/XMLHttpRequest(под общим названием XHR здесь и далее) не взорвалась до 2005 года, когда Джесси Джеймс Гарретт опубликовал свою статью «Ajax: новый подход к веб-приложениям».
Ajax распахнул двери для веб-разработки, и на переднем плане были JavaScript, XHR и DHTML — два из которых были изобретения Microsoft. Итак, что случилось? Что заставило браузер, который буквально изменил то, как веб-разработчики пишут веб-приложения, стать проклятием современного Интернета?
Падение Internet Explorer
К 2003 году общая доля рынка Internet Explorer составляла около 95%; Microsoft официально выиграла войну браузеров. В условиях отсутствия реальной конкуренции в веб-пространстве Microsoft переключила свое внимание с браузера на .NET. Это подтверждается цитатами из многих сотрудников Microsoft, но наиболее красноречивым является статья CNET под названием «Поможет ли Ajax Google очистить?» В ней Чарльз Фитцджеральд, генеральный менеджер Microsoft по платформенным технологиям, сказал:
«Немного удручает то, что разработчики только сейчас задумываются об этих вещах, которые мы отправляли в конце 20-го века [ed: DHTML и Ajax] , но XAML относится к совершенно другому классу. Этот другой материал очень клёвый, очень сложный для отладки. Мы видели несколько довольно впечатляющих хаков, но если вы посмотрите на то, что XAML начинает решать, это серьезный шаг вперед ».
Поэтому в мае 2003 года Microsoft объявила, что IE больше не будет выпускаться отдельно от Windows (отличный IE5 для Mac также был готов). Браузер по-прежнему будет разрабатываться как часть развивающейся операционной системы Windows, но Microsoft не будет выпускать какие-либо автономные версии IE. В основном они делали ставку на ClickOnce, технологию, которая позволяет разработчикам писать обычные приложения (конечно, с использованием .NET) и распространять их через Интернет.
Но Интернет продолжал развиваться по пути, который Microsoft изначально установил с IE4 и IE5, и Microsoft начала терять долю рынка наследнику Netscape: Firefox. Разработчики писали веб-приложения, которые жили в браузере, а не в обычных приложениях через ClickOnce. Это заставило Microsoft взять IE, вычистить его и снова начать выпускать автономные версии.
Microsoft продолжает внедрять инновации
IE9, включает гораздо лучшую поддержку стандартов по всем направлениям.
Следующие две версии, 7 и 8, были в значительной степени эволюционными. IE7 содержал множество исправлений ошибок, идентификатор XMLHttpRequest (хотя он все еще создавал объект XMLHttp из библиотеки MSXML) и улучшения пользовательского интерфейса и безопасности.
IE8 был в значительной степени похож на другой, за исключением того, что он помещал в песочницу каждую вкладку — функция, которую Google также реализовал в Chrome (Microsoft объявила об этом первой). Он изолирует каждую вкладку в своем собственном процессе, повышая безопасность и стабильность. Песочница становится стандартом в современных браузерах (Firefox все еще не имеет такой возможности), и она также переходит в сферу дополнений и плагинов.
Microsoft возвращает Internet Explorer в нужное русло.
Последняя версия, IE9, включает в себя гораздо лучшую поддержку стандартов по всем направлениям, но она также вводит новшества с новым движком JIT-компиляции JavaScript (который использует отдельное ядро ЦП, если оно доступно и может обращаться к ГП) и механизмом рендеринга с аппаратным ускорением. Хотя движки JIT-компиляции JavaScript не новы, способность IE9 переносить компиляцию на отдельное ядро параллельно с рендерингом страниц — это достижение, которое будет стимулировать столь необходимую производительность для веб-приложений. Его возможности аппаратного ускорения оказались полезными при дебюте, и теперь Firefox и Chrome в некоторой степени предлагают аппаратное ускорение.
Нельзя отрицать, что Internet Explorer вызвал головную боль у веб-разработчиков. Пятилетнее затишье между IE6 и IE7 привело к тому, что Microsoft сильно отстала от конкурентов, что сделало разработку интерфейсов далеко не идеальной. Но Microsoft возвращает Internet Explorer в нужное русло. Они сделали веб-разработку такой, какая она есть сегодня; здесь надеются, что они сделают это снова.
Следующая версия Internet Explorer, версия 9 , будет официально выпущена 14 марта 2011 года.