Вам, скорее всего, доводилось слышать словосочетания «прогрессивное улучшение» и «плавное сокращение возможностей». Под ними подразумеваются методологии, к которым прибегают, когда речь идет о сильно различающейся браузерной поддержке. При этом они вызывают ожесточенные дебаты среди членов веб-сообщества. Хотя сначала может показаться, что между ними есть что-то общее, на самом деле эти два понятия в корне противоположны. Вот мое пояснение.
Плавное сокращение возможностей подразумевает создание сайта для современных браузеров и гарантирует, что для пользователей определенных устаревших браузеров будет обеспечено приемлемое взаимодействие. Функции деградируют в устаревших браузерах, при этом обычно есть «точка прерывания», начиная с которой наиболее устаревшие браузеры больше не поддерживаются. Кроме того, в некоторых случаях пользователи просто предупреждаются о том, что с их браузерами возникла проблема, и для них предлагаются пути ее решения (например, «ваш браузер сильно устарел — обновите его!»).
Прогрессивное улучшение — это противоположность плавного сокращения возможностей. Прогрессивное улучшение подразумевает разметку, соответствующую веб-стандартам, то есть она будет понятна всем браузерам (невзирая на такие технологии, как JavaScript и даже CSS). Качество обеспечиваемого взаимодействия затем будет прогрессивно улучшаться для более совместимых браузеров с помощью CSS-стилизации и в конечном счете JavaScript (если потребуется).
О преимуществах и недостатках каждого из этих подходов написано сотни статей. На вашем месте я для начала заглянул бы на сайт разработчика браузера Opera по адресу http://dev. opera.com/artides/view/graceful-degradation-progressive-Enhancement/, а также прочел бы отличную статью веб-разработчика Аарона Гюс-тафсона (Aaron Gustafson), которая доступна по адресу http://www.alistapart.com/ articles/understandingprogressiveenhancement.
Реальность. В настоящее время многие веб-специалисты считают прогрессивное улучшение наилучшим подходом при разработке сайтов. И хоть я по большому счету отдаю предпочтение этой методологии и использую ее при создании сайтов, жестокая правда состоит в том, что может возникнуть множество ситуаций, когда, вероятно, лучше прибегнуть к плавному сокращению возможностей. Как же так?
Кодовую базу сайта andthewinnerisnt.com, который мы только что создали, образует HTML5. Устаревшие браузеры, например Internet Explorer версий 6, 7 и 8 (далее по ходу книги они будут называться устаревшими версиями браузера Internet Explorer), были созданы и выпущены в свет до появления HTML5 (который, как вы помните, является неутвержденным стандартом, несмотря на то что становится все более распространенным). По этой причине им непонятно, для чего предназначены элементы <aside>, <section> и <footer>. Таким образом, если мыслить как пурист, можно сказать, что не следует использовать HTML5-элементы. Если для решения проблемы, связанной с базовой функциональностью, добавить фрагмент JavaScript-кода, то разве это будет прогрессивным улучшением?
Несмотря на это, я всегда предпочитаю использовать HTML5 вместо HTML 4.01, если только нет веской причины поступить по-другому. Реальность такова, что если смотреть с позиции работы, которой я занимаюсь неделя за неделей, то HTML5 имеет больше преимуществ, чем недостатков. Поэтому при использовании этой версии языка разметки (что я вам, безусловно, рекомендую делать) давайте всем устройствам возможность проявить себя в полную силу в обработке HTML5-кода, написав его в соответствии с требуемыми стандартами (используйте валидатор по адресу http://validator. nu/ или http://validator. w3.org/ для устранения всех ошибок).
Тем не менее вы неизбежно столкнетесь с ситуацией, когда придется сделать часть расширенной функциональности, которую предлагают современные браузеры, доступной в устаревших версиях Internet Explorer. Например, вам потребуется обеспечить поддержку свойства border-radius. Однако прежде, чем вы займетесь этим, я хочу еще кое о чем вам рассказать.
Добавить комментарий