Веб-сайты не обязательно должны выглядеть одинаково в каждом браузере.
Рекомендации
Designing With Progressive Enhancement by Filament Group
Глава 7: Проблемы
Четвертая ежегодная конференция по
гипертексту состоялась в Сан-Антонио, штат Техас, в декабре 1991 года. Проект Тима Бернерса-Ли "World Wide Web" тогда только начинал формироваться. Полагая, что организаторы и участники конференции оценят проект, он подал предложение на Hypertext '91. Предложение было отклонено.
Гипертекстовое сообщество считало проект World Wide Web слишком упрощенным. Почти каждая другая гипертекстовая система включала концепцию двусторонней связи. Если ресурс перемещается, любые ссылки, указывающие на этот ресурс, автоматически обновляются. Сеть не давала таких гарантий. Его система ссылок была намного проще – вы просто ссылаетесь на что-то, и все. Организаторам «Гипертекста-91» это казалось безнадежно наивным. Они не понимали, что простота Интернета на самом деле была его силой. Поскольку связывание было таким простым, любой мог это сделать. Это окажется решающим фактором в принятии и успехе Всемирной паутины.
Слишком велик соблазн быстро заявить, что тот или иной подход наивен, чрезмерно упрощен и нереалистичен. Идея о том, что веб-сайт может одновременно обеспечивать универсальный доступ для всех и одновременно предоставлять богатый опыт погружения для более мощных устройств… тоже кажется безнадежно наивной.
Это решение выносилось много раз за всю историю существования сети.
"Это слишком просто"
Когда проект Web Standards Project начал кампанию, призывающую дизайнеров перейти с таблиц для верстки на CSS, она встретила сопротивление. Их снова и снова критиковали за наивность. "Конечно, макет на основе CSS может подойти для простого персонального сайта, но он никак не может подойти для большого сложного проекта".
Затем Даг Боуман возглавил CSS-редизайн сайта Wired.com, а Майк Дэвидсон – CSS-редизайн сайта ESPN.com. После этого открылись шлюзы.
Когда Итан Маркотте продемонстрировал возможности отзывчивого дизайна, это встретило сопротивление. "Конечно, отзывчивый дизайн может подойти для простого персонального сайта, но он никак не может быть масштабирован для большого сложного проекта".
Затем газета Boston Globe запустила свой отзывчивый сайт. Microsoft сделала свою домашнюю страницу отзывчивой. Снова открылись шлюзы.
Сегодня похожая история. "Конечно, прогрессивное улучшение может сработать для простого персонального сайта, но оно никак не может подойти для большого сложного проекта".
Шлюзы готовы к открытию. Нам просто нужно, чтобы вы создали постер для устойчивого веб-дизайна.
"Это слишком сложно"
Создание устойчивых веб-сайтов – сложная задача. Требуется время для продуманного многоуровневого применения функциональности и возможностей. В результате вы получаете сайт, который может лучше реагировать на неожиданные обстоятельства – необычные браузеры, нестабильные сетевые соединения, устаревшие устройства. Тем не менее, для многих веб-дизайнеров временные затраты кажутся слишком высокими.
Стоит помнить, что создание с прогрессивным улучшением не означает, что все должно быть доступно каждому. Вместо этого важна основная функциональность. Если бы каждая функция должна была быть доступна в каждом браузере на каждом устройстве, это был бы действительно невероятно трудный процесс. Вот почему так важна расстановка приоритетов. Пока основная функциональность доступна с использованием максимально простой технологии, вы можете с чистой совестью добавлять более продвинутые функции.
Тем не менее вполне возможно, что такой подход приведет к дублированию работы. Если вы создадите старомодный клиент-серверный процесс отправки формы, а затем улучшите его с помощью JavaScript, вы можете в конечном итоге повторить обработку формы как на клиенте, так и на сервере. Этого можно избежать, если вы также используете JavaScript на сервере. Теоретически возможно написать универсальный JavaScript, чтобы сервер и браузер использовали единую кодовую базу. Даже без универсального JavaScript я все же думаю, что стоит потратить время на создание технического кредита.
В руководстве по проектированию государственной службы Великобритании приводится еще более краткая форма трехэтапного процесса, который я описал:
Во-первых, просто заставить его работать
Во-вторых, сделать так, чтобы работало лучше