Ненавязчивый JavaScript - это общий подход к использованию JavaScript на веб-страницах . Хотя этот термин формально не определен, его основные принципы , как правило , понимаются разделение функциональности (далее «поведение слоя») с веб - страницы структуры / содержания и презентации , [1] и прогрессивное усиление для поддержки пользовательских агентов , которые не могут поддерживать определенные функции JavaScript и пользователи, отключившие JavaScript. [2]
Обзор
Появление совместимых со стандартами браузеров , фреймворков JavaScript и высококачественных инструментов отладки сделало возможным организованный, масштабируемый код JavaScript, а появление интерфейсов Ajax сделало это желательным. В то время как JavaScript раньше использовался для относительно простых и некритичных задач, таких как проверка форм и декоративные новинки, теперь он используется для написания больших и сложных кодовых баз , которые часто являются частью основной функциональности сайта.
Концепция «ненавязчивости» по отношению к программированию на JavaScript была введена в 2002 году Стюартом Лэнгриджем [3] в статье «Ненавязчивый DHTML и возможности неупорядоченных списков». [4] В статье Лэнгридж доказывал, что весь код JavaScript, включая обработчики событий, должен быть вне HTML. С тех пор Стюарт Лэнгридж развил эту мысль в книге [5] и в формате статьи. [6]
Другие авторы пытались уточнить и определить основные элементы ненавязчивости. В книге Дэвида Фланагана « JavaScript: окончательное руководство» говорится, что, хотя конкретной формулы не существует, существуют три основные цели:
- Чтобы отделить JavaScript от разметки HTML, а также сохранить независимость модулей JavaScript от других модулей.
- Ненавязчивый JavaScript должен постепенно ухудшаться - весь контент должен быть доступен без успешного выполнения всего или какого-либо JavaScript.
- Ненавязчивый JavaScript не должен ухудшать доступность HTML, а в идеале должен улучшать его, независимо от того, имеет ли пользователь личные недостатки или использует необычный или необычно настроенный браузер. [7]
Проект веб-стандартов описал четыре преимущества ненавязчивого написания сценариев DOM в своем манифесте JavaScript .
- Удобство использования : ненавязчивый сценарий DOM не привлекает внимания пользователя - посетители используют его, не задумываясь об этом.
- Изящная деградация : ненавязчивые сценарии DOM никогда не генерируют сообщения об ошибках ни в одном браузере, даже если они терпят неудачу. Если функции не могут быть представлены должным образом, они молча исчезают.
- Доступность : если какой-либо сценарий не работает, страница по-прежнему предоставляет свои основные функции и информацию через разметку, таблицы стилей и / или сценарии на стороне сервера.
- Разделение : в интересах других и будущих веб-разработчиков весь код JavaScript поддерживается отдельно, не влияя на другие файлы сценария, разметки или кода. [8]
На Парижской веб-конференции 2007 года Кристиан Хейльманн определил семь правил ненавязчивого JavaScript. [9]
- Не делайте никаких предположений: методы защитного программирования должны учитывать возможности того, что JavaScript может не работать, браузер может не поддерживать ожидаемые методы, HTML может быть изменен, могут использоваться неожиданные устройства ввода, а другие сценарии могут отсутствовать или может посягать на глобальное пространство имен.
- Найдите свои зацепки и связи, такие как идентификаторы и другие аспекты ожидаемого HTML.
- Оставьте обход отдельных объектов DOM экспертам, например, обработчику CSS, встроенному в браузер, где это возможно.
- Поймите браузеры и пользователей, в частности, как они терпят неудачу, какие предположения они делают, а также необычные конфигурации или способы использования.
- Узнайте о событиях , в том числе о том, как они «всплывают», и об особенностях
Event
объекта, который передается большинству обработчиков событий. - Хорошо играйте с другими скриптами, избегая глобальных имен функций и переменных.
- Работайте на следующего разработчика, используя понятные имена переменных и функций, создавая логичный и читаемый код, делая зависимости очевидными и комментируя любой код, который все еще может сбивать с толку.
Отделение поведения от разметки
Традиционно JavaScript часто помещался в строку вместе с разметкой HTML-документа. Например, вот типичный способ зарегистрировать обработчик событий JavaScript в HTML:
type = "text" name = "date" onchange = "validateDate ()" />
Целью разметки HTML является описание структуры документа, а не его программного поведения. Их сочетание может негативно повлиять на ремонтопригодность сайта, например сочетание контента и представления . [10] Поведение JavaScript, созданное и упомянутое в HTML, может быть сложнее в использовании и обслуживании, например, при установке обработчиков для нескольких событий для одного элемента, при установке одного и того же обработчика событий для нескольких элементов или при использовании делегирования событий .
Ненавязчивое решение - зарегистрировать необходимые обработчики событий программно, а не встроенно. Вместо того, чтобы onchange
явно добавлять атрибут, как указано выше, соответствующие элементы просто идентифицируются, например class
, id
или другими способами в разметке:
type = "text" name = "date" id = "date" />
Сценарий, который запускается при первой загрузке страницы в браузер, затем может искать каждый соответствующий элемент и настраивать его соответствующим образом:
окно . addEventListener ( "DOMContentLoaded" , функция ( событие ) { документ . getElementById ( 'дата' ). addEventListener ( "изменение" , validateDate ); });
Пространства имён
Ненавязчивый JavaScript должен как можно меньше добавлять к глобальному объекту или глобальному пространству имен среды, в которой он работает. Другие сценарии могут переопределить любую переменную или функцию, созданную в глобальном пространстве имен, и это может привести к неожиданным сбоям, которые трудно отлаживать. JavaScript не имеет встроенного механизма явного пространства имен, но желаемые эффекты легко получить с помощью средств языка. Фланаган предлагает использовать собственное доменное имя разработчика с перевернутыми пунктирными сегментами в качестве единого глобального имени для публикации, которое, скорее всего, будет уникальным, в стиле, разработанном на языке Java . [11]
var org = org || {}; if ( typeof org ! == 'object' ) { throw new Error ( "организация уже определена как не-объектная" ); }орг . example = org . пример || {}; if ( typeof org . example ! == 'object' ) { throw new Error ( "org.example уже определен как не объект" ); }
Хотя переменные, функции и объекты всех видов могут быть дополнительно определены в таких объектах пространства имен, обычно рекомендуется использовать замыкания в пространстве имен для дальнейшей изоляции того, что станет частными переменными и функциями, а также для экспорта того, что будет общедоступным интерфейсом. каждого модуля функциональности. За приведенным выше кодом может непосредственно следовать следующий код, который использует IIFE для установления своего закрытия: [9]
орг . пример . Выделите = ( функция () { // Определение личных данных и функции вар highlightId = 'х' ; функция setHighlight ( цвет ) { документ . GetElementById ( highlightId .) Стиль . Цвет = цвет ; } // Возвращаем общедоступные указатели на функции или свойства, // которые должны быть общедоступными. return { goGreen : function () { setHighlight ( 'зеленый' ); }, goBlue : function () { setHighlight ( 'синий' ); } } } ()); // Конец закрытия
Из любого другого модуля эти общедоступные методы могут быть вызваны любым способом следующим образом
орг . пример . Выделите . goBlue ();var h = org . пример . Выделите ; ч . goGreen ();
Таким образом, код каждого разработчика модуля содержится в частном или уникальном пространстве имен и не может вмешиваться или вторгаться в любой другой код в любое время.
Изящно деградируя
Написание прослушивателя событий, который обнаруживает загрузку HTML-страницы, а затем добавляет соответствующие прослушиватели к другим событиям на странице, а также к другому поведению по мере необходимости, может решить проблему отделения функциональности JavaScript от разметки HTML. Использование клиентских библиотек JavaScript, таких как jQuery , MooTools или Prototype, может упростить этот процесс и помочь обеспечить скрытие и учет деталей конкретного браузера и его версии . Хранение большей части JavaScript вне пространства имен по умолчанию помогает сделать его максимально ненавязчивым в этом смысле. Еще один критерий ненавязчивого JavaScript, который часто упоминается, заключается в том, чтобы гарантировать, что добавленное поведение корректно ухудшается в тех браузерах с неожиданными конфигурациями, а также в тех, в которых пользователь мог полностью отключить JavaScript. [7]
Это требование является основным принципом веб-доступности , чтобы гарантировать, что веб-сайты с расширенным JavaScript не только могут использоваться людьми со всеми способностями и ограниченными возможностями, но и чтобы все пользователи - независимо от их вычислительной платформы - получали равный доступ ко всей информации и функциям сайта. Иногда для этого требуется дополнительная работа, но во многих странах доступность Интернета не является обязательной. Например, в Великобритании Закон о равенстве 2010 года , хотя он прямо не касается доступности веб-сайтов, запрещает дискриминацию людей с ограниченными возможностями и распространяется на всех, кто предоставляет какие-либо услуги в государственном, частном и добровольном секторах. [12] Хотя можно приложить немало усилий для разработки и реализации приятного пользовательского интерфейса на стороне клиента на ненавязчивом JavaScript, он не останется незаметным для пользователя без сценариев на стороне клиента, если они обнаружат, что не могут получить доступ к опубликованной информации. Для достижения этой цели часто необходимо реализовать эквивалентные, хотя и более громоздкие, функциональные возможности на стороне сервера, которые будут доступны вообще без использования JavaScript.
Возьмем, к примеру, веб-страницу, на которой для миниатюрных изображений требуется поведение JavaScript, чтобы полноразмерные изображения появлялись перед страницей при наведении на них указателя мыши или при нажатии на них. Во-первых, разметка на стороне сервера должна гарантировать, что соответствующее полноразмерное изображение предоставляется пользователям без JavaScript, которые нажимают на миниатюру. В этом случае базовая разметка HTML для каждого эскиза может выглядеть следующим образом:
< HREF = "полноразмерный-образ-001.png" класс = "ручная ссылка" название = "Нажмите для полноразмерных изображений" > < IMG SRC = "образом-001-thumb.png" класс = "большой палец" ширина = "50" height = "50" alt = "Изображение 1 показывает ... и т. Д." > A >
Это будет работать без JavaScript. В этом случае ненавязчивый JavaScript во время загрузки страницы может найти все a
элементы, имеющие класс, manual-link
и удалить их из DOM страницы. Затем он может найти все изображения класса thumb
и присоединить обработчик событий onmouseover
или onclick
обработчик событий, который указан в строке, чтобы обеспечить плавное поведение. Например, при вызове обработчик событий может отправить запрос Ajax на сервер для полноразмерного изображения, а затем добавить div
на страницу DOM, вызывая существующий CSS, чтобы он отображался перед существующим содержимым, которое само по себе может стать частично серым. div
Потребуется кнопка закрытия, возможно , визуальные «вертушку» , чтобы показать , что данные загрузки и т.д. И, наконец, когда данные поступают Ajax, обработчик скрывает вертушка и вставляет полноразмерное изображение в новом div
для отображения.
Таким образом, все клиентские функции зависят от одной и той же функции JavaScript. Если эта функция завершается успешно, она начинается с удаления базового ручного поведения и продолжается добавлением сценариев на стороне клиента. Если сценарий не работает по какой-либо причине, ручное поведение остается на месте и остается работоспособным.
Лучшие практики
Хотя суть ненавязчивого JavaScript заключается в концепции добавленного отдельного уровня поведения, его сторонники обычно придерживаются ряда связанных принципов, таких как:
- Соответствие стандартам, то есть соблюдение W3C DOM и модели событий, а также отказ от расширений, специфичных для браузера.
- Обнаружение возможностей , т. Е. Тестирование определенных функций перед их использованием. [13] В частности, это рассматривается как противоположность обнаружению браузером.
- В более общем плане, лучшие практики JavaScript часто совпадают с лучшими практиками других языков программирования, такими как уровни инкапсуляции и абстракции , избегание глобальных переменных , значимые соглашения об именах , использование соответствующих шаблонов проектирования и систематическое тестирование .
Смотрите также
- Изящная деградация
- Прогрессивное улучшение
Рекомендации
- ^ Кейт, Джереми (2006-06-20). «Поведенческое разделение» .
- ^ Олссон, Томми (6 февраля 2007 г.). «Изящная деградация и прогрессивное улучшение» .
- ^ «Создание динамических сайтов» . 2006-08-09 . Проверено 18 мая 2010 .
- ^ Лэнгридж, Стюарт (ноябрь 2002 г.). «Ненавязчивый DHTML и мощь неупорядоченных списков» . Проверено 7 августа 2008 .
- ^ Лэнгридж, Стюарт (2005). DHTML Utopia: современный веб-дизайн с использованием JavaScript и DOM . SitePoint. ISBN 0-9579218-9-6. (Ссылка на первое издание, поскольку оно показывает, как автор впервые применил эту концепцию.)
- ^ Например: Лэнгридж, Стюарт (2005-06-01). «Утопия DHTML: современный веб-дизайн с использованием JavaScript и DOM» . Проверено 18 октября 2016 .
- ^ а б Фланаган, Дэвид (2006). JavaScript: Полное руководство (5-е изд.). O'Reilly & Associates. п. 241 . ISBN 0-596-10199-6.
- ^ «Манифест JavaScript» . Проект веб-стандартов . Проверено 8 февраля 2011 года .
- ^ а б Хейльманн, Кристиан (2007). «Семь правил ненавязчивого JavaScript» . Архивировано из оригинального 2 -го мая 2011 года . Проверено 8 февраля 2011 года .
- ^ «Модель веб-стандартов - HTML, CSS и JavaScript» . Учебная программа по веб-стандартам W3C . W3C. 2014 . Дата обращения 16 мая 2016 .
- ^ Фланаган, Дэвид (2006). «10». JavaScript: Полное руководство (5-е изд.). O'Reilly & Associates. ISBN 0-596-10199-6.
- ^ «Закон о равенстве 2010 года» . Канцелярия Ее Величества . Проверено 7 сентября 2011 года .
- ^ «Dev.Opera - Использование возможности обнаружения» . Проверено 19 октября +2016 .