Принципы ненавязчивого JavaScript

Введение

В предыдущих лекциях было много сказано о HTML и CSS, и о том, как правильно их реализовать, а также были рассмотрены основы JavaScript - что это такое, что можно сделать с его помощью, и почему необходимо знать этот язык. Прежде чем переходить к подробному рассмотрению практического применения JavaScript, нужно остановиться и подумать о том, как использовать JavaScript благоразумно, чтобы он никому не ограничивал доступ к Web-сайту. Это основная идея ненавязчивого JavaScript. Чтобы лучше понять, что это такое, и почему нам это нужно, давайте рассмотрим множество неопределенностей связанных с программированием JavaScript:

Это достаточно длинный список проблем, многие из которых не являются техническими по своей природе, но скорее концептуальными, или, если хотите, философскими. Кроме того, хотя последние две проблемы могут также возникать в других языках программирования, первые четыре являются исключительными для среды программирования JavaScript, так что опыт программирования здесь не поможет.

Говоря коротко, ненавязчивый JavaScript есть способ написания JavaScript таким образом, чтобы посетители сайта не ушли с сайта в связи с одной из вышеперечисленных причин - даже если JavaScript работает для них некорректно, они все равно смогут использовать сайт, хотя и на более низком уровне. Данная лекция обсуждает принципы и практику ненавязчивого JavaScript, и ненавязчиво настраивает вас на оставшуюся часть курса.

Лекция имеет следующую структуру:

Определение ненавязчивого JavaScript

Чтобы эффективно обойти перечисленные выше проблемы, прежде всего, необходимо понять, что вы делаете и почему. Нам требуется теория правильной разработки JavaScript.

Такую теорию предоставляет ненавязчивый JavaScript. Это не технические приемы как таковые; ненавязчивый JavaScript не является вопросом добавления в сценарии одной функции makeUnobtrusive(), чтобы войти в нирвану. Наоборот, это образ мышления. Чтобы гарантировать, что сценарии никому не причиняют неудобства, необходимо гарантировать, что сценарии не делают никаких предположений.

В данный момент "не делают предположений" является достаточно трудной задачей. К счастью можно разделить ненавязчивость на три категории: сценарий должен быть ненавязчивым для пользователей, браузеров, и программистов.

В данной лекции достаточно подробно рассматриваются два первых предположения. Третья категория будет рассмотрена в отдельной лекции.

Кроме исключения этих предположений, ненавязчивый код JavaScript требует правильного разделения кода JavaScript и HTML. Так как это, несомненно, наиболее технический аспект этой философии программирования, он будет рассмотрен первым, а затем мы перейдем к нашим предположениям.

Разделение структуры и поведения

Также как мы должны разделять структуру и представление, помещая весь код CSS в отдельный файл и избегая использования атрибутов style или другой аналогичной разметки представления, мы должны также разделять структуру HTML и поведение JavaScript. Причины те же самые: это разделяет возможные проблемы, сохраняет код чистым, и позволяет работать с JavaScript, не прикасаясь к HTML или CSS.

Основное правило очень простое: файл HTML не должен содержать никакого кода JavaScript, также как он не должен содержать никакого кода CSS. Существуют две вещи, которые авторы JavaScript помещают в файлы HTML: встроенные сценарии и обработчики событий. Удаление их является простейшим способом добиться разделения структуры и поведения.

Как вы узнали в предыдущей лекции, встроенные сценарии являются фрагментами кода JavaScript внутри страницы HTML между тегами <script>. Их можно легко переместить во внешний файл JavaScript, поэтому они не создают проблем.

Встроенные обработчики событий, такие как <a href="somewhere.html" onmouseover="hideAll()">, исключить несколько труднее. Они определяют, какие обработчики событий (функции JavaScript) должны выполняться, когда происходит определенное событие. Чтобы сделать код ненавязчивым, необходимо перенести это задание обработчика событий в отдельный файл сценария. Это означает, что внешний сценарий сначала должен найти правильный элемент, а затем присвоить ему обработчика событий.

Чтобы больше узнать об обработчиках событий, прочитайте лекцию 11, Обработка событий с помощью JavaScript.

Простейший способ, позволяющий находить элемент, состоит в задании для него ID. Например:

<!- HTML: ->
<a href="somewhere.html" id="somewhereLink">

<!- JavaScript: ->
var x = document.getElementById('somewhereLink');
if (x) {
  x.onmouseover = hideAll;
}

Функция hideAll() выполняется всякий раз, когда пользователь проводит указателем мыши над ссылкой, и этот фрагмент кода эквивалентен следующему

<a href="somewhere.html" onmouseover="hideAll()">.

Более того, эти две строки кода работают на каждой странице, которая содержит элемент с id="somewhereLink", поэтому не требуется повторяться. А если страница не содержит такой элемент, проверка if (x) гарантирует, что не будет создаваться никаких сообщений об ошибке: обработчик событий назначается только в том случае, когда элемент x фактически существует.

А что если браузер пользователя не поддерживает JavaScript? Очевидно, что mouseover не будет работать. Однако ссылка остается ссылкой, и может по-прежнему использоваться для перехода.

Теперь наш код, кроме того, что стал чище, стал также более легко обслуживаемым.

Например, часто бывает удобно соединять события mouseover и focus парами. Событие mouseover работает, только когда пользователь использует мышь. Люди, которые не используют мышь, будут перемещать фокус клавиатуры на ссылку, на которой они хотят щелкнуть, и это включает событие focus. Если зарегистрировать функцию обработки события на этом событии тоже (что означает, если мы укажем функцию, которая должна запускаться этим событием), мы заставим наше приложение работать также и с клавиатурой.

Это очень легко сделать, когда сценарий правильно отделен от HTML:

var x = document.getElementById('somewhereLink');
if (x) {
  x.onmouseover = x.onfocus = hideAll;
}

Добавляя 12 символов, мы сделали эту часть приложения доступной для клавиатуры. Легко, не правда ли?

Теперь давайте представим себе, что пришлось бы делать, если бы использовались встроенные обработчики событий. Мы должны были бы вручную пройтись по всем ссылкам на всем сайте и добавить onfocus="hideAll()" во все ссылки, которые имеют обработчик событий onmouseover. Мы не только должны будем затратить много времени, которое можно было бы потратить на что-нибудь полезное, но это также подверженный ошибкам способ работы, так как очень легко пропустить ссылку в запутанном шаблоне, который используется в очень специальных случаях, или просто неправильно ввести одну из строк onfocus.

Поэтому, также как очень разумно разделять HTML и CSS, в равной степени правильная мысль состоит в разделении HTML и JavaScript. Удаление встроенных сценариев и встроенных обработчиков событий выполняется достаточно просто, и это немедленно улучшает качество и легкость обслуживания кода.

Добавление слоя юзабилити

Теперь, когда мы закончили с наиболее технической частью ненавязчивого JavaScript, пришло время вернуться к рассмотренным ранее предположениям. Самое важное из них состоит в том, что никогда не надо предполагать, что все поддерживают JavaScript, и это соединяется непосредственно с общей целью добавления сценариев на Web-сайт.

Назначение JavaScript состоит в добавлении на сайт слоя юзабилити. Подчеркнем слово "добавление": если сценарий является всем слоем юзабилити (другими словами, если сайт будет непригоден для использования без JavaScript), то мы сделаем серьезную ошибку, и сценарий нельзя будет назвать ненавязчивым.

Пример - проверка формы

Пример внесет в это ясность, поэтому давайте обсудим проверку формы. Ввод пользователя в форму должен всегда проверяться на сервере, прежде чем помещаться в базу данных. Доверие данным, которые случайный пользователь (возможно, злоумышленный) вводит в форму, является самым быстрым и надежным способом подвергнуть свой сайт злоумышленной атаке - мы должны всегда проверять полученные данные, прежде чем признавать их.

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

Даже хуже, если пользователь сделает ошибку - например, не введет свой адрес - ему придется исправить проблему и снова отправить форму, что ведет к следующему полусекундному ожиданию. Это на самом деле не так много времени, но это складывается в голове пользователя, особенно, если ему придется сделать это несколько раз.

Именно здесь на сцене появляется JavaScript. Если добавить сценарий, который проверяет форму перед отправкой на сервер, типичные ошибки пользователя будут перехвачены без взаимодействия с сервером, и будет казаться, что интерфейс работает значительно быстрее и более гладко.

Поэтому использование сценария JavaScript для проверки формы будет хорошей идеей. Однако - и это важно - необходимо использовать JavaScript в дополнение к серверной проверке формы. Проверка у клиента дает более гладкий интерфейс, но только серверная проверка обеспечивает надлежащую безопасность (очень легко обойти проверку JavaScript, если вы намерены нанести ущерб: надо просто отключить JavaScript), а также резервный вариант на тот случай, если браузер пользователя не поддерживает JavaScript.

В начале 2009 г. (это могло уже измениться к настоящему времени) браузер Opera имел преимущество относительно других браузеров, так как поддерживал спецификацию HTML 5 ), которая является, по сути, более развитым способом использования форм в HTML, включая встроенные в клиентскую часть средства проверки форм, которые не требуют JavaScript, и поэтому их невозможно обойти, отключая JavaScript. Чтобы больше узнать о Web Forms 2.0, прочтите лекцию Улучшение работы форм с помощью HTML 5 (http://dev.opera.com/articles/view/improve-your-forms-using-html5/).

Принципы

Этот пример подчеркивает несколько важных принципов:

Теперь давайте посмотрим, что в точности означает: "Сайт должен работать без JavaScript"? Это означает, что любой пользователь, какое бы устройство просмотра или программное обеспечение он не использовал, должен иметь возможность прочитать содержимое сайта и использовать навигацию и другие критически важные функции. Ничего больше, но и, что более важно, ничего меньше.

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

Фактически это общее правило. Когда JavaScript отключен, страдает юзабилити, и задача web-разработчика состоит в том, чтобы гарантировать, что люди смогут использовать основные возможности сайта: содержимое и навигацию. Все остальные свойства становятся необязательными.

Пример - всплывающие окна

В качестве другого примера рассмотрим всплывающие окна. Иногда они бывают крайне полезными, и создать их достаточно просто - если браузер поддерживает JavaScript. Однако, если это не так, то пользователи не увидят всплывающее окно. Как сохранить свой сайт доступным, предоставляя при этом браузерам с поддержкой JavaScript более гибкий интерфейс?

В HTML:
<a href="somewhere.html" class="popup">Go somewhere</a>

В JavaScript:
var x = document.getElementsByClassName('popup'); // a custom function
for (var i=0;i<x.length;i++=1) {
	x[i].onclick = function () {
		window.open(this.href,'popup','arguments');
		return false;
	}
}

Критическим моментом здесь является атрибут href ссылки. Он определяет страницу, которая должна быть показана во всплывающем окне, но, кроме того, гарантирует, что если JavaScript будет отключен, пользователь все равно сможет перейти по ссылке. Поэтому этот пример вполне доступен и без JavaScript - просто менее удобно.

Когда JavaScript включен, можно добавить дополнительный слой юзабилити: всплывающее окно. Вы находите все ссылки, которые имеют class="popup", и добавляете обработчик событий onclick, который открывает всплывающее окно. Какую страницу должно показать всплывающее окно? Ту, которая определена в атрибуте href ссылки ( this.href ).

Еще один пример, те же самые принципы. Сначала надо убедиться, что все пользователи могут получить доступ к информации, а затем добавить немного JavaScript поверх этого, чтобы сделать интерфейс более привлекательным.

Пример - Ajax

Эту теорию иногда трудно применить на практике, особенно, когда вы являетесь относительным новичком разработки Web, и хотите создать, скажем, сайт Ajax. Полезный прием, чтобы освоиться с этой техникой, состоит в представлении слоистой структуры. Что является базовой функциональностью сайта? Эта функциональность должна размещаться в самом нижнем слое, который доступен как с помощью JavaScript, так и без нее. Поверх этого можно приложить любое число управляемых JavaScript слоев юзабилити, которые облегчают использование сайта. Эти слои не мешают базовой функциональности сайта, они просто предлагают некоторые приятные дополнения.

Пример поясняет это общее правило. Предположим, что сайт посвящен сравнению мобильных телефонов. Базовая функциональность этого сайта будет выглядеть примерно следующим образом:

Все эти функции могут создаваться без использования JavaScript, и первая задача состоит в том, чтобы сделать именно так. Поэтому вы создаете:

Когда эти страницы без сценариев будут сделаны, вы тем самым создаете базовый слой, который будет в некоторой степени работать в любом браузере на любом устройстве.

После этого можно добавить на эти страницы функции JavaScript. Наиболее очевидным является сценарий сортировки. В конце концов, данные, необходимые для сортировки - такие как цены и свойства - уже представлены в таблице на странице, и не требуется выполнять обращение к серверу, чтобы их получить. Необходимо просто написать сценарий, который считывает данные из таблицы и затем сортирует все <tr> из этой таблицы.

Когда сценарий будет написан, необходимо проверить, что пользователь может его действительно использовать Предоставление пользователю ссылки для этой цели является наиболее очевидным решением.

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

Поэтому вы пишете дополнительную функцию, которая присваивает обработчики событий onclick этим ссылкам, чтобы гарантировать, что щелчок на них вызывает сценарий сортировки, а не страницу на сервере.

Таким образом, все пользователи видят одни и те же ссылки на сортировки, но их точное поведение зависит от того, может ли браузер обрабатывать дополнительный слой юзабилити на JavaScript. Если может, то он запускает сценарий, если - нет, он извлекает новую страницу с сервера.

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

Чистый, семантический HTML

Сценарии выполняются в контексте Web страниц. Web страниц какого вида? Теоретически подойдет любая страница, если на ней имеется несколько элементов HTML, которыми можно манипулировать. На практике, однако, вы быстро обнаружите, что значительно легче иметь дело с удовлетворяющими стандартам Web-страницами, которые используют семантический, структурированный HTML, и правильно разделяют свой HTML и CSS, чем с WYSIWYG-сгенерированными, опирающимися на таблицы чудовищами.

Предположим, что вы работаете над новостным сайтом и хотите, чтобы каждая страница содержала оглавление со ссылками на контент, которое соединяется со всеми заголовками новостных статей. Простейший способ сделать это - состоит в просмотре страницы в поисках всех тегов заголовков ( <h1>, <h2>, и т.д.), создании списка, и проверке, что щелчок на ссылке пересылает пользователя к соответствующему заголовку. Создав сценарий можно переходить к следующему заданию. (Между прочим, этот сценарий также ненавязчивый. Для функции перехода к заголовку хорошо бы иметь дополнительные возможности, но если их нет здесь, пользователь все равно сможет читать страницу и использовать навигацию.)

Предположим теперь, что Web-сайту, над которым вы работаете, не настолько повезло, чтобы он был создан с помощью семантического HTML и CSS, о которых вы узнали. Предположим, что он выглядит следующим образом:

<div class="contentcontainer">
  <p class="maincontent"><b class="headline">McCain suspends campaign to spend more time with his economy</b><br>
  In a move that shocked political observers ... [etc etc]</p>
</div>

Можно ли по-прежнему написать сценарий оглавления для такой ужасно размеченной страницы? Конечно, можно. Пройдитесь просто по всем тегам <b> и предположите, что каждый из них, который имеет class="headline", является фактически заголовком - и сценарий будет работать.

Тем не менее, одну вещь мы теперь потеряли, отсутствует структурное вложение, которое неявно присутствует в уровнях заголовков. Чистая, семантическая страница немедленно сообщает, что заголовок <h3> будет подзаголовком предыдущего заголовка <h2>, и сценарий может использовать этот факт для своих целей.

Для несемантической страницы, такой как представлена выше, необходимо найти другие способы определения, что некоторый тег <b class="headline"> используется как основной заголовок, подзаголовок, под-подзаголовок или как-то иначе.

Теперь даже эта проблема может быть решена, но не это главное. Основная проблема в том, что если автор HTML использует правильные теги заголовков для разметки заголовков, то вы абсолютно уверены, что ваш сценарий найдет правильную информацию, не важно где или когда он выполняется. И наоборот, если автор HTML использует такие вещи как <b class="headline">, то он в действительности не знает, что делает, что означает, что следующая версия HTML может легко переключиться, например, на теги <strong> или <span>.

И всякий раз при изменении HTML вы должны будете также изменять свой сценарий.

Поэтому сценарии, которые работают с чистыми, семантическими страницами, обычно легче писать, и всегда значительно легче поддерживать, чем сценарии, которые работают с мешаниной тегов.

Совместимость браузеров

Ненавязчивый JavaScript также призывает создавать сценарии, которые будут ненавязчивыми для браузеров. На практике это означает, что сценарий должен работать в максимально возможном числе браузеров, и если он не работает, он не должен создавать сообщения об ошибках, он должен вместо этого снижать производительность, оставляя посетителей сайта со страницей, которая будет, тем не менее, предоставлять работающую функциональность. Это звучит прекрасно, но является для изучения одним из самых трудных аспектов разработки JavaScript.

Ведущий специалист по JavaScript Дуглас Крокфорд называет браузер "самой враждебной средой программирования в мире." Браузер не только не является настоящей прикладной платформой (пока еще), но имеет плохую репутацию в отношении предоставления таких вещей как отладчики (однако здесь также ситуация изменяятся к лучшему), но огромное количество различий между ними может быстро свести с ума начинающих разработчиков JavaScript.

К сожалению, несовместимость браузеров является фактом жизни. Как только вы попытаетесь написать какой-либо нетривиальный JavaScript, вы обнаружите, что поведение различных браузеров может существенно отличаться. Чаще всего сценарий будет работать во всех браузерах за исключением IE, хотя другие браузеры тоже имеют свою долю проблем.

Основная причина этих несовместимостей состоит в том, что большинство основных браузеров имеют свой собственный процессор JavaScript для синтаксического анализа, интерпретации и выполнения сценариев, и эти процессоры различаются между собой.

Наиболее частым источником проблем является Internet Explorer, существует множество функций, которые работают отлично от других браузеров, или просто не поддерживаются. Команда разработчиков MSIE работает над тем, чтобы сделать свой браузер более соответствующим стандартам. Но пока работа эта не закончена. Поэтому можно ожидать появления некоторых проблем.

Даже если эта проблема будет магическим образом разрешена, большое число несовместимостей будут продолжать существовать, просто потому что какой-то процессор JavaScript может еще не поддерживать определенный метод, или потому что программисты сделали откровенную ошибку при его реализации.

Поэтому здесь имеется проблема, и она никуда не исчезнет в ближайшее время. Как с ней справиться?

Лучшей стратегией является признание и сосредоточение на практически важных технических деталях, которые будут рассмотрены дальше в этой серии статей. Доскональное изучение всех несовместимостей браузеров к сожалению невозможно, но существует несколько средств помощи начинающим программистам JavaScript. Например, QuirksMode.org (http://quirksmode.org/) предлагает таблицы совместимости, которые четко показывают, какие браузеры поддерживают какие методы и свойства, и предоставляют обширные заметки об ошибках.

Кроме того, многие люди прошли по этой дороге раньше. Некоторые их них создали библиотеки JavaScript, которые помогают обойти худшие проблемы. Поэтому использование библиотек для разрешения проблем несовместимости браузеров является жизненно важной стратегией.

Тем не менее, слово предостережения. Начинающий разработчик JavaScript должен серьезно рассмотреть возможность написания своего первого большого проекта без помощи библиотек. Причина в том, что всесторонне образованный разработчик JavaScript должен много поработать, чтобы получить глубокое понимание, что происходит в реальности. В этом случае вы получите тонко отточенное интуитивное чувство того, как браузеры могут исказить сценарии, что поможет при разработке сценариев JavaScript.

Итак, используйте библиотеки для обхода существующих проблем, но не поддавайтесь соблазну начинать использовать их незамедлительно. Попробуйте поработать без них, чтобы получить представление, с чем вы сталкиваетесь.

Заключение

Ненавязчивый JavaScript является в большей степени философией программирования, чем техническим навыком. Несомненно, наиболее важным компонентом его является четкое понимание, какие функции принадлежат какому уровню. Все абсолютно критически важные функции сайта должны быть закодированы на обычном HTML, но после создания этой основы можно добавить слой JavaScript поверх базовых функций, чтобы предоставить браузерам, которые его поддерживают, более удобный, чистый и быстрый интерфейс.

Более того, ненавязчивый JavaScript

Ненавязчивый JavaScript не настолько труден. Это скорее привычка мышления, если затратить несколько часов на планирование одного ненавязчивого JavaScript, вы обнаружите, что принятие правильных решений становится все проще и проще.

Когда вы привыкните к использованию ненавязчивого JavaScript, вы вряд ли захотите возвратиться к старой навязчивой модели.

Об авторе

Питер-Поль Кох является Web-разработчиком фрилансером из Амстердама, Голландия. Он создал и поддерживает сайт quirksmode.org, в настоящее время один из лучших ресурсов по JavaScript в Интернет. В частности. его Таблицы Совместимости W3C DOM сохранили много нервных клеток web-разработчикам со всего мира. Поставщики браузеров, такие как Microsoft, Opera, и Apple используют эти таблицы при поиске ошибок в своих программах.