Не прощать
Свободная обработка ошибок в HTML позволила ему со временем набрать силу. Это также обеспечило простоту изучения языка. Даже если вы допустили ошибку, реализация браузером закона Постеля гарантировала, что вы все равно получите результат. Удивительно, но была попытка удалить эту суперспособность из HTML.
После стандартизации HTML версии 4 в 1999 году Консорциум Всемирной паутины опубликовал XHTML 1.0. В нем HTML был переформулирован в соответствии с правилами формата данных XML. В то время как в HTML имена тегов и атрибутов могут быть прописными или строчными, XML требует, чтобы они были полностью строчными. Были и другие различия: все атрибуты должны быть заключены в кавычки, а отдельные элементы, такие как IMG или BR, требуют закрывающей косой черты.
XHTML 1.0 не добавил в язык никаких новых возможностей. Это был просто более строгий способ написания разметки. XHTML 2.0 был совсем другим предложением. Он не только удалял такие устоявшиеся элементы, как IMG, но и внедрял драконовскую модель обработки ошибок XML. Если в XML-документе есть хоть одна ошибка – один атрибут без кавычек или пропущенная закрывающая косая черта – то синтаксический анализатор должен немедленно остановиться и отказаться что-либо отображать.
XHTML 2.0 умер на лозе. Его теоретическая чистота была отвергнута людьми, которые действительно зарабатывали на жизнь созданием веб-сайтов. Веб-дизайнеры справедливо отказались от публикации в формате, который может полностью провалиться вместо того, чтобы попытаться восстановиться после ошибки.
Странно, что спустя годы веб-дизайнеры с удовольствием создавали целые веб-сайты с помощью JavaScript, языка, который разделяет неумолимую модель обработки ошибок XML. Они не называли их веб-сайтами. Они называли их веб-приложениями. Это различие было холодным утешением для тех, кто не мог выполнить свою задачу из-за того, что сервис полагался на JavaScript для критически важной функциональности.
Несмотря на хрупкую модель обработки ошибок JavaScript, веб-дизайнеры со временем все больше полагались на JavaScript. В 2015 году NASA перезапустило свой веб-сайт как веб-приложение. Если вы хотели прочитать последние новости о работе агентства по освоению космоса, вам сначала нужно было загрузить и выполнить три мегабайта JavaScript. Это содержимое – текст и изображения – могло быть передано в HTML, но разработчики решили использовать Ajax для получения этих данных. Пока весь этот JavaScript не был загружен, разобран и выполнен, посетители сайта смотрели на черный фон. Возможно, это было задумано как демонстрация огромной одинокой пустоты космоса.
Версия сайта nasa.gov 2015 года с неполным JavaScript.
Это подчеркивает еще одно различие между HTML и JavaScript. В то время как HTML можно просматривать по частям по мере загрузки, файл JavaScript должен быть загружен полностью, прежде чем его содержимое будет разобрано. Хотя очень заманчиво думать, что лишь небольшое меньшинство посетителей сайта пропустит JavaScript, правда заключается в том, что все являются пользователями без JavaScript до тех пор, пока JavaScript не закончит загрузку… если JavaScript закончит загрузку. Нестабильные соединения, вмешательство операторов сети и непредсказуемое программное обеспечение, блокирующее рекламу, могут разрушить предположение о том, что JavaScript всегда будет доступен.
Проблема не в том, что люди намеренно отключают JavaScript в своих браузерах. Хотя такой вариант использования стоит рассмотреть, это не самая распространенная причина ошибок JavaScript. Стюарт Лэнгридж составил список всех потенциальных точек отказа под заголовком "У всех есть JavaScript, верно?
«Пользователь запрашивает ваше веб-приложение. Загрузилась ли страница? Успешен ли HTTP-запрос для JavaScript? Завершился ли HTTP-запрос для JavaScript? Блокирует ли корпоративный брандмауэр JavaScript? Не препятствует ли провайдер или оператор мобильной связи загрузке JavaScript? Отключили ли они JavaScript? Установлены ли у них дополнения или плагины, которые внедряют сценарий или изменяют DOM таким образом, как вы не ожидали? Работает ли сеть доставки контента? Поддерживает ли их браузер написанный вами JavaScript?»
Многие из этих проблем также могут повлиять на файлы HTML и CSS, но благодаря закону Постеля они могут изящно восстановиться.
Это не означает, что веб-дизайнеры не должны использовать JavaScript. Но это означает, что веб-дизайнеры не должны полагаться на JavaScript, когда существует более простое решение.
Платформа
Веб-дизайнеры, проигнорировавшие посыл книги Джона Оллсоппа "Дао веб-дизайна", совершили ошибку, отнесясь к вебу как к печатной продукции. История печати может многое предложить – иерархию, типографику, теорию цвета, но веб – это принципиально иной носитель информации. История разработки программного обеспечения также может многое предложить – архитектуру, тестирование, процесс, но, опять же, веб остается собственным носителем информации.