Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Часть серии по
JavaScript
Язык
Библиотеки
Реализации
Смотрите также

Ненавязчивый 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 .

  1. Удобство использования : ненавязчивый сценарий DOM не привлекает внимания пользователя - посетители используют его, не задумываясь об этом.
  2. Изящная деградация : ненавязчивые сценарии DOM никогда не генерируют сообщения об ошибках ни в одном браузере, даже если они терпят неудачу. Если функции не могут быть представлены должным образом, они молча исчезают.
  3. Доступность : если какой-либо сценарий не работает, страница по-прежнему предоставляет свои основные функции и информацию через разметку, таблицы стилей и / или сценарии на стороне сервера.
  4. Разделение : в интересах других и будущих веб-разработчиков весь код JavaScript поддерживается отдельно, не влияя на другие файлы сценария, разметки или кода. [8]

На Парижской веб-конференции 2007 года Кристиан Хейльманн определил семь правил ненавязчивого JavaScript. [9]

  1. Не делайте никаких предположений: методы защитного программирования должны учитывать возможности того, что JavaScript может не работать, браузер может не поддерживать ожидаемые методы, HTML может быть изменен, могут использоваться неожиданные устройства ввода, а другие сценарии могут отсутствовать или может посягать на глобальное пространство имен.
  2. Найдите свои зацепки и связи, такие как идентификаторы и другие аспекты ожидаемого HTML.
  3. Оставьте обход отдельных объектов DOM экспертам, например, обработчику CSS, встроенному в браузер, где это возможно.
  4. Поймите браузеры и пользователей, в частности, как они терпят неудачу, какие предположения они делают, а также необычные конфигурации или способы использования.
  5. Узнайте о событиях , в том числе о том, как они «всплывают», и об особенностях Eventобъекта, который передается большинству обработчиков событий.
  6. Хорошо играйте с другими скриптами, избегая глобальных имен функций и переменных.
  7. Работайте на следующего разработчика, используя понятные имена переменных и функций, создавая логичный и читаемый код, делая зависимости очевидными и комментируя любой код, который все еще может запутать.

Отделение поведения от разметки [ править ]

Традиционно JavaScript часто помещался в строку вместе с разметкой HTML-документа. Например, вот типичный способ зарегистрировать обработчик событий JavaScript в HTML:

<input  type = "text"  name = "date"  onchange = "validateDate ()"  />

Целью разметки HTML является описание структуры документа, а не его программного поведения. Их сочетание может негативно повлиять на ремонтопригодность сайта, например сочетание контента и представления . [10] Поведение JavaScript, созданное и упомянутое в HTML, может быть сложнее в использовании и обслуживании, например, при установке обработчиков для нескольких событий для одного элемента, при установке одного и того же обработчика событий для нескольких элементов или при использовании делегирования событий .

Ненавязчивое решение - зарегистрировать необходимые обработчики событий программно, а не встроенно. Вместо того, чтобы onchangeявно добавлять атрибут, как указано выше, соответствующие элементы просто идентифицируются, например class, idили другими способами в разметке:

<input  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 часто совпадают с лучшими практиками других языков программирования, такими как уровни инкапсуляции и абстракции , избегание глобальных переменных , значимые соглашения об именах , использование соответствующих шаблонов проектирования и систематическое тестирование .

См. Также [ править ]

  • Изящная деградация
  • Прогрессивное улучшение

Ссылки [ править ]

  1. ^ Кейт, Джереми (2006-06-20). «Поведенческое разделение» .
  2. ^ Olsson, Томми (2007-02-06). «Изящная деградация и прогрессивное улучшение» .
  3. ^ «Создание динамических веб-сайтов» . 2006-08-09 . Проверено 18 мая 2010 .
  4. ^ Лэнгриддж, Стюарт (ноябрь 2002). «Ненавязчивый DHTML и мощь неупорядоченных списков» . Проверено 7 августа 2008 .
  5. ^ Лэнгридж, Стюарт (2005). DHTML Utopia: современный веб-дизайн с использованием JavaScript и DOM . SitePoint. ISBN 0-9579218-9-6. (Ссылка на первое издание, поскольку оно показывает, как автор впервые применил эту концепцию.)
  6. ^ Например: Лэнгридж, Стюарт (2005-06-01). «Утопия DHTML: современный веб-дизайн с использованием JavaScript и DOM» . Проверено 18 октября 2016 .
  7. ^ a b Фланаган, Дэвид (2006). JavaScript: Полное руководство (5-е изд.). O'Reilly & Associates. п. 241 . ISBN 0-596-10199-6.
  8. ^ «Манифест JavaScript» . Проект веб-стандартов . Проверено 8 февраля 2011 года .
  9. ^ a b Хейльманн, Кристиан (2007). «Семь правил ненавязчивого JavaScript» . Архивировано из оригинального 2 -го мая 2011 года . Проверено 8 февраля 2011 года .
  10. ^ «Модель веб-стандартов - HTML, CSS и JavaScript» . Учебная программа по веб-стандартам W3C . W3C. 2014 . Дата обращения 16 мая 2016 .
  11. ^ Фланаган, Дэвид (2006). «10». JavaScript: Полное руководство (5-е изд.). O'Reilly & Associates. ISBN 0-596-10199-6.
  12. ^ "Закон о равенстве 2010" . Канцелярия Ее Величества . Проверено 7 сентября 2011 года .
  13. ^ "Dev.Opera - Использование обнаружения возможностей" . Проверено 19 октября +2016 .