Самый быстрый способ выучить английский язык
Раздел: Сайтостроение / JavaScript /
JavaScript в разных браузерах
Веб-браузер – это универсальная платформа для исполнения приложений, а JavaScript – это язык программирования, на котором эти приложения разрабатываются.
Хорошая новость в том, что JavaScript достаточно стандартизирован и имеет широкую поддержку - все современные браузеры поддерживают стандарт ECMAScript.
Однако есть и плохая новость - это сама платформа (то есть непосредственно особенности самих браузеров).
Все браузеры могут отображать HTML-документы, но они отличаются друг от друга полнотой поддержки других стандартов, таких как CSS и DOM. И хотя все современные браузеры включают совместимые реализации интерпретатора JavaScript, они имеют отличия в прикладном программном интерфейсе (Application Programming Interface, API), доступном для клиентского JavaScript-кода.
Поэтому разработчики могут столкнуться (и сталкиваются) с неприятностями, связанными с работой создаваемого ими кода в разных браузерах.
Разрабатываемый и распространяемый вами JavaScript-код может исполняться на различных версиях разных браузеров и в разных операционных системах. Допустим, что мы хотим создать рабочий код для таких комбинаций операционных систем и браузеров:
- Internet Explorer в Windows
- Internet Explorer в Mac OS
- Firefox для Windows
- Firefox для Mac OS
- Firefox для Linux
- Safari для Mac OS
- Opera для Windows
- Opera для Mac OS
- Opera для Linux
Если у вас появится желание реализовать поддержку всех этих браузеров, плюс две предыдущие версии каждого из них, то умножьте эти девять комбинаций три, и вы получите 27 комбинаций браузера, версии и операционной системы.
Единственный способ убедиться, что ваши веб-приложения будут правильно исполняться в любой из 27 комбинаций – это проверить каждую комбинацию.
На практике обычно никто этого не делает. В итоге пользователь часто получает устойчивое отвращение к какому-либо сайту. Я, например, однажды потратил несколько часов только для того, чтобы зарегистрировать проект для экспертизы на госуслугах.
Но Госуслуги - это бюджетный проект. Могут себе позволить наплевательское отношение к пользователю. Коммерческий же проект такого себе позволить не может. Поэтому, разрабатывая веб-приложения на JavaScript, вы должны, как минимум, знать о несовместимости браузеров, а как максимум - предусмотреть все эти несовместимости. То есть ваш код должен быть совместим со всеми возможными комбинациями, ну или хотя бы с описанными выше 27-ю.
Сделать это непросто, и в данной статье, конечно, я не научу вас это делать. Это лишь обзорная статья для общего понимания. Но надо с чего-то начинать. Почему бы и не с этой статьи?
Происхождение несовместимости
При JavaScript-программировании на стороне клиента всегда приходилось сталкиваться с проблемой несовместимости. На заре веб-программирования шла война браузеров между Netscape и Microsoft. Это было время бурного развития браузеров и API-интерфейсов клиентского JavaScript, часто в несовместимых направлениях. Проблемы несовместимости в этот период проявлялись наиболее остро, и некоторые сайты для их преодоления просто сообщали своим посетителям, какой броузер они должны использовать.
Война браузеров завершилась, когда корпорация Microsoft заняла доминирующее положение на рынке, а веб-стандарты, такие как CSS и DOM, стали приобретать все большее влияние.
Сегодня Microsoft уже не так сильна на рынке браузеров, и ей пришлось делать свои браузеры более-менее совместимыми с остальными. Однако несовместимость никуда не делать. Быть может, только чуть уменьшилась.
Кроме того, развитие не прекращается. Устраняются старые несовместимости, но появляются новые. Так что жизнь программиста JavaScript никогда не будет лёгкой.
Проверка особенностей
Проверка особенностей (она же проверка функциональных возможностей) – это очень мощный способ, позволяющий справиться с проблемами совместимости. Особенность, или функциональная возможность, которую вы собираетесь использовать, может поддерживаться не всеми браузерами. Поэтому необходимо включать в свои сценарии программный код, который будет проверять факт поддержки данной особенности. Если требуемая особенность не поддерживается на текущей платформе, тогда можно будет либо не использовать эту особенность на данной платформе, либо разработать альтернативный программный код, одинаково работоспособный на всех платформах.
С другой стороны, лучше сразу писать такой код, который заведомо будет поддерживаться всеми браузерами. Хотя часто очень сложно, а иногда и невозможно. Но стремиться к этому надо…
Пример проверки особенностей:
function handler(){}
function CheckingFeatures()
{
//Найти элемент по имени
var element = document.getElementById("mybtn");
//Проверить наличие метода W3C перед вызовом
if (element.addEventListener)
{
element.addEventListener("keydown", handler, false);
element.addEventListener("keypress", handler, false);
alert("Есть W3C");
}
else
//Проверить наличие метода IE перед вызовом
if (element.attachEvent)
{
element.attachEvent("onkeydown", handler);
element.attachEvent("onkeypress", handler);
alert("Есть IE");
}
//В противном случае использовать универсальный прием
else
{
element.onkeydown = element.onkeypress = handler;
alert("Нет ни W3C, ни IE");
}
}
Здесь мы проверяем соответствие платформы на наличие каких-то возможностей. Например, сначала мы проверяем,
имеется ли у объекта element метод addEventListener. Если имеется, то назначаем обработчики событий для этого элемента с помощью этого метода.
Если же такого метода не имеется, то браузер не соответствует стандарту W3C. Тогда мы идём дальше и смотрим,
имеется ли у элемента метод attachEvent. Если да, то мы используем для назначения обработчика этот метод. Ну и так далее.
Самое главное, что дает проверка особенностей – это программный код, который не привязан к конкретным браузерам или их версиям. Этот прием работает со всеми браузерами, существующими ныне, и должен продолжить работать с будущими версиями браузеров независимо от того, какой набор особенностей они реализуют.
Однако следует отметить, что производители браузеров не должны определять свойства и методы, не обладающие
полной функциональностью. Если бы корпорация Microsoft определила метод addEventListener, реализовав спецификации W3C лишь частично, это привело бы к нарушениям работоспособности большого числа сценариев, в которых перед вызовом этого метода реализован механизм проверки особенностей.
Также для решения проблем совместимости можно проверить тип браузера и дальше уже действовать в зависимости от результата. Есть и некоторые другие хитрые нестандартные решения. Однако к нестандартным решениям следует прибегать только в крайних случаях, потому что они могут перестать поддерживаться в любой момент, как говорится, без предупреждения.
Возможно, я об этом ещё расскажу. Но в следующих статьях...