Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Если бы каждый разработчик думал о том как себя будет вести сайт без javascript…
Возможно, сейчас я получу лучи добра и жесткий слив, но сейчас сложно представить себе типичного пользователя без js. Стоит ли тратить время на заботу о пользователе без js — вопрос сложный и зависит от многих факторов.
Плохо ли это? Да, пожалуй плохо. Забочусь ли я о таких пользователях постоянно (т.е. от проекта к проекту)? Ответ — нет.
Плохо ли это? Да, пожалуй плохо. Забочусь ли я о таких пользователях постоянно (т.е. от проекта к проекту)? Ответ — нет.
Тут идея такая. Сначала пишется простейший базовый функцинал, который не нуждается в js. А следующим слоем он расширяется с помощью js. Где тут дополнительные затраты времени? Всё равно придется писать всю ту же логику на js, что и обычно.
Да тут особо спорить не о чем. Это же все индивидуально от проекта к проекту, как мне кажется. Например — отправка формы в фоне: конечно у формы есть action и если js у пользователя не включен, то форма просто отправится «естественным образом». Но тут забота о пользователе проявляется постольку-поскольку. Как вы уже сказали: базовый функционал и так есть. Или к примеру карусель изображений ( типа jcarousel, JQuery Cycle и т.д.) изображения и так выводятся и если не включен js, то они будут показаны и можно даже облагородить их вывод.
А вот другой пример: fancybox. Нужно по клику куда-либо показать окошко с информацией. И нет js. Как быть? Очевидного решения я не вижу, такого что б совсем без затрат времени.
Прошу прощения если примеры вдруг показались вам наивными. Первое, что пришло в голову.
А вот другой пример: fancybox. Нужно по клику куда-либо показать окошко с информацией. И нет js. Как быть? Очевидного решения я не вижу, такого что б совсем без затрат времени.
Прошу прощения если примеры вдруг показались вам наивными. Первое, что пришло в голову.
Значит надо спроектировать интерфейс так чтобы js не потребовался. Если нужно показать картинку в полном размере — пожалуйста, прямая ссылка.
И вообще верстальщик и дизайнер всегда должны задавать себе вопросы: а что если пользователь не загрузил js, css или картинки? Как будет выглядеть такой сайт?
Только такой подход считаю правильным.
И вообще верстальщик и дизайнер всегда должны задавать себе вопросы: а что если пользователь не загрузил js, css или картинки? Как будет выглядеть такой сайт?
Только такой подход считаю правильным.
Ну с картинками — вопрос простой. Нет обработчика — переход по ссылке.
А вот, например, авторизация через соц. сети?
Вы не подумайте что я рву майку за обязательное наличие js. Я просто веду к тому, что тут вопрос довольно «интимный» и зависит как от заказчика так и от исполнителя и даже от аудитории сайта, как мне кажется. Просто в каждом случае нужно подходить индивидуально. Что, конечно же ни как не идет в разрез с общими правилами «хорошего тона» по типу нет js — переходим по ссылке и т.д. Это же очевидно, как по мне.
А вот, например, авторизация через соц. сети?
Вы не подумайте что я рву майку за обязательное наличие js. Я просто веду к тому, что тут вопрос довольно «интимный» и зависит как от заказчика так и от исполнителя и даже от аудитории сайта, как мне кажется. Просто в каждом случае нужно подходить индивидуально. Что, конечно же ни как не идет в разрез с общими правилами «хорошего тона» по типу нет js — переходим по ссылке и т.д. Это же очевидно, как по мне.
Авторизация через соц. сети это другой вопрос (она идёт как бы бонусом), но своя авторизация точно должна спокойно работать без javascript.
А вот, например, авторизация через соц. сети?
Что касается авторизации в соц. сетях, то она как раз отлично работает и без js.
Есть класс сайтов, в которых основной составляющей является именно js, взять те же Яндекс.Карты и сервисы, их использующие или тот же htmlacademy. На подобных проектах очень сложно сделать что-то внятное без js.
Остальные же сайты, на которых js не слишком сложный и его не слишком много, должны делаться с заботой о содержании, а потом уже с заботой о рюшечках. Это, конечно, личное дело каждого, но по таким мелочам виден профессиональный уровень и любовь к своему делу =)
Что касается авторизации в соц. сетях, то она как раз отлично работает и без js.
Если я не ошибаюсь, то мы говорим о дополнительных затратах:
Где тут дополнительные затраты времени? Всё равно придется писать всю ту же логику на js, что и обычно.
И это как раз случай дополнительных трудозатрат. Не так ли?
а что если пользователь не загрузил js, css или картинки? Как будет выглядеть такой сайт?
Паршиво :)
Нужно по клику куда-либо показать окошко с информацией. И нет js. Как быть? Очевидного решения я не вижу, такого что б совсем без затрат времени.
Если информация уже на страничке, но спрятана, то просто без JS диалог не прячется и располагается где-то под подвалом. Кнопка вызова диалога должна иметь реальную локальную ссылку (#fancybox). После надатия на такую кнопку без JS пользователь будет переброшен к нужной ниформации или форме ввода.
Если информация не присутствует на странице, то лучше всего её хранить по какому нибудь адресу (REST наше всё). После щелчка по кнопке (ссылке) без JS мы переходим по адресу с веб-формой или информацией. Если JS есть, то веб-форма или информация подкачивается и вставляется в страничку.
Лично для себя я нахожу три причины почему сайт должен работать без js:
1. Так изначально задуман вэб, javascript добавляет интерактивность и лишь безболезненно расширяет базовый функционал заложенный в html, но не заменяет собой такие базовые вещи как URI и сайт должен работать нормально и без javascript.
2. Поисковики. Да, гугл бот научился распознавать javascript, но такая индексация занимает три дня (недавно была статья), не все поисковые боты такие умные.
3. Opera Mini.
Может я старомодный в этом плане, но когда я вижу сайты которые работают без javascript а с ним лишь получают дополнительный user experience — хочется пожать разработчику руку.
Один из хороших примеров здесь это форумный движок XenForo. Очень грамотная реализация этой идеи. (особое внимание на ajax)
1. Так изначально задуман вэб, javascript добавляет интерактивность и лишь безболезненно расширяет базовый функционал заложенный в html, но не заменяет собой такие базовые вещи как URI и сайт должен работать нормально и без javascript.
2. Поисковики. Да, гугл бот научился распознавать javascript, но такая индексация занимает три дня (недавно была статья), не все поисковые боты такие умные.
3. Opera Mini.
Может я старомодный в этом плане, но когда я вижу сайты которые работают без javascript а с ним лишь получают дополнительный user experience — хочется пожать разработчику руку.
Один из хороших примеров здесь это форумный движок XenForo. Очень грамотная реализация этой идеи. (особое внимание на ajax)
Если сайт приносит недостаточно пользы, чтобы оправдать добавление исключения в NoScript, такой сайт идет лесом.
Почему NoScript? Потому что безопасность + по умолчанию отсутствие раздражающих сюрпризов вроде ненужных музыки/флэша/снежинок и т.д.
Почему NoScript? Потому что безопасность + по умолчанию отсутствие раздражающих сюрпризов вроде ненужных музыки/флэша/снежинок и т.д.
Возможно, сейчас я получу лучи добра и жесткий слив, но сейчас сложно представить себе типичного пользователя без js.
Всё просто:
— Представьте google (yandex, whatever) бота
— представьте функциональное авто-тестирование своим краулером (с behat например)
Да есть много краулеров поддерживающих JS, но они не так просты, надежны, быстры. Впрочем как порой и JS функционал в отсутствие системы описанной в статье.
С тестирование не совсем понял. Если мне нужно тестировать фронтенд, то какой мне толк от того, что у меня все работает без js (и оттестировано), если моя аудитория на 90% состоит из клиентов с js.
Я чего-то не так понял?
Мы сейчас об одних и тех же «типичных пользователях» говорим?
Я чего-то не так понял?
сложно представить себе типичного пользователя без js.
представьте функциональное авто-тестирование своим краулером (с behat например)
Мы сейчас об одних и тех же «типичных пользователях» говорим?
Краулеры тоже «пользователи», и если SEO у вас не на последнем месте, то такие же VI«P» как и остальные.
А с тестированием так: вы можете тестировать JS функционал селениумом. Вопрос — надо ли это делать in the first place. Обычно JS-причиндалы это только маленькая вершинка айсберга. Ну если только у вас не все приложение — джаваскриптовый айсберг, что значит или вы работаете в гугл, или вы что-то овер-инжинирите. Бо´льшая часть большинства проектов легко тестируется обычным get/post краулером, и JS в этих проектах для простоты рассчитывает (и фолбэкается на) те же самые get/post. Только тесты проверяющие JS =on режим будут выполняться часами, а не минутами.
Даже если аудитория на 99% состоит из клиентов с JS, это девелоперу же лучше сводить любые процессы к простым легко-тестируемые и, соответственно, легко-дебажным механизмам (a href, onsubmit, post, get), по сравнению с запутанными коллбэками с трудновоспроизводимыми кейсами «кликни тут, тут и тут, смотри вывод стектрейса в файербаге, сделай изменение в коде, повтори всё снова».
А с тестированием так: вы можете тестировать JS функционал селениумом. Вопрос — надо ли это делать in the first place. Обычно JS-причиндалы это только маленькая вершинка айсберга. Ну если только у вас не все приложение — джаваскриптовый айсберг, что значит или вы работаете в гугл, или вы что-то овер-инжинирите. Бо´льшая часть большинства проектов легко тестируется обычным get/post краулером, и JS в этих проектах для простоты рассчитывает (и фолбэкается на) те же самые get/post. Только тесты проверяющие JS =on режим будут выполняться часами, а не минутами.
Даже если аудитория на 99% состоит из клиентов с JS, это девелоперу же лучше сводить любые процессы к простым легко-тестируемые и, соответственно, легко-дебажным механизмам (a href, onsubmit, post, get), по сравнению с запутанными коллбэками с трудновоспроизводимыми кейсами «кликни тут, тут и тут, смотри вывод стектрейса в файербаге, сделай изменение в коде, повтори всё снова».
Google Bot уже умеет исполнять JavaScript. Скоро и остальные подтянутся.
Вот например, мобильный хабр отвратительно работает с JS.
Медленный интерфейс, если набирать ответ, буквы появляются по одной (зачем перехватывать ввод?..)
Иногда возникают неприятные глюки:
А если JS отключить, то страница ведет себя как и положено — очень шустро. Правда, не работает отправка комментариев и нельзя голосовать…
(В саппорт писал, даже несколько раз — бесполезно, говорят, проблема только у меня)
Медленный интерфейс, если набирать ответ, буквы появляются по одной (зачем перехватывать ввод?..)
Иногда возникают неприятные глюки:
Скрытый текст
А если JS отключить, то страница ведет себя как и положено — очень шустро. Правда, не работает отправка комментариев и нельзя голосовать…
(В саппорт писал, даже несколько раз — бесполезно, говорят, проблема только у меня)
Ссори, а это перевод что ли? Если да, то можно ссылочку на оригинал плз?)
Нет, это не переводная статья, это статья из нашего корпоративного блога, решили поделиться с Хабром.
Когда вы с помощью картинок делаете кнопку такой же красивой в старых браузерах (из-за фирменного стиля или просто требования заказчика) — это уже изящная деградация
Нет.
Изящная деградация — это отключение неподдерживаемых фич без ущерба основному функционалу.
Пример: картинки с Lightbox.
Изящная деградация — это возможность увидеть увеличенный размер картинки, пройдя по прямой ссылке, если по какой-то причине js событие для загрузки Lightbox не сработало.
Graceful Degradation — это не совсем отказоустойчивость.
Основной смысл в том, что сайт работает хорошо, красиво и быстро в последних версиях браузеров, хорошо и красиво/быстро в устаревших и просто как-то работает в древних.
Т.е. там основной упор на то, что чем старее браузер — тем хуже выглядит и работает сайт, но работает.
Т.е. мы делаем современный сайт, со всеми модными фишками, но который будет работать и без них (ненавязчивый js, например).
Причем при разработке зачастую используется описанный вами случай, поэтому тут нет противостояния терминов.
Основной смысл в том, что сайт работает хорошо, красиво и быстро в последних версиях браузеров, хорошо и красиво/быстро в устаревших и просто как-то работает в древних.
Т.е. там основной упор на то, что чем старее браузер — тем хуже выглядит и работает сайт, но работает.
Т.е. мы делаем современный сайт, со всеми модными фишками, но который будет работать и без них (ненавязчивый js, например).
Причем при разработке зачастую используется описанный вами случай, поэтому тут нет противостояния терминов.
Полезная серия книг в тему заметки.
Теперь действительно хорошие разработчики и дизайнеры могут делать progressive enhancement, а плохие не могут, так как это сложнее и трудозатратнее.
Здесь с автором не соглашусь в плане «сложнее и трудозатратнее». Писать сначала разметку, потом добавлять оформление и поведение — на мой взгляд, это не сложнее. И более того — приятнее, мне лично доставляет удовольствие размечать документ чистым HTML, думать как поддержать семантику документа, какой тег уместнее и т. д. Если какой-то верстальщик не любит этого делать, то у меня для него плохие новости. В итоге же прогрессивное улучшение не трудозатратнее, ведь пытаясь соблюсти принципы изящной деградации, вы в принципе делаете то же самое — обеспечиваете функциональность в старых браузерах. Я бы даже сказал, что оба подхода в идеале суть одно и то же, разница в том, когда вы начинаете думать о том, как это будет выглядеть в IE6 или на старом телефоне, — сразу или после того, как напишете CSS3 и JS.
Это, конечно, здорово, но на дворе конец 2012-го, сейчас уже даже ddos по javascript фильтруют (nginx testcookie, например), есть ли смысл тратить ресурсы на устаревших клиентов?
Мне кажется, здесь размыто понятие «веб-интерфейс» между интерфейсом одностраничных веб-приложения (RIA), где HTML-документ как основа приложения уже не подходит, и интерфейсом веб-сайта, форума, блога, где HTML-документ наиболее подходит в качестве основы.
Для первых «gracefull degradation» в части случаев невозможна в принципе из-за необходимости всего стека доступных технологий для предоставления функций веб-приложения, а в другой части может иметь вид разве что отдельно разработанного с нуля упрощенного интерфейса (пример — почтовые веб-клиенты, где можно привести работу с почтой как работу с HTML-документами).
Для вторых эта концепция действительно имеет место быть в полном объеме: посетителю предоставляется контент, а не функциональность.
Многие пытаются объединить эти две несовместимых области (например, проект jQuery UI), и это запутывает.
Для первых «gracefull degradation» в части случаев невозможна в принципе из-за необходимости всего стека доступных технологий для предоставления функций веб-приложения, а в другой части может иметь вид разве что отдельно разработанного с нуля упрощенного интерфейса (пример — почтовые веб-клиенты, где можно привести работу с почтой как работу с HTML-документами).
Для вторых эта концепция действительно имеет место быть в полном объеме: посетителю предоставляется контент, а не функциональность.
Многие пытаются объединить эти две несовместимых области (например, проект jQuery UI), и это запутывает.
В целом, да, примерно так и надо. С другой стороны, на умеренно-загруженном сайте у нас за 3 месяца было ровно 2 пользователя без js, около 40 на старых ie и около 40000 всех остальных. Какой смысл?
Я за то, чтобы сайты были правильно размечены и радикально против того, чтобы с помощью JS затыкать дыры верстки — но жертвовать ради совместимости, например, плейсхолдерами — да ну в пень такую совместимость.
Я за то, чтобы сайты были правильно размечены и радикально против того, чтобы с помощью JS затыкать дыры верстки — но жертвовать ради совместимости, например, плейсхолдерами — да ну в пень такую совместимость.
мне кажется, что корни GrDe можно поискать еще и в процессах разработки.
а. как правило верстальщик получает от дизайнера макет, на котором страница представлена уже со всеми наворотами, и на выходе требуется результат «на 100% соответствующий макету в современных браузерах».
б. без вдумчивого анализа из макета бывает сложно понять, какие фичи жизненно важны, а какими можно жертвовать.
это только две причины, из-за которых первая версия страницы создается с полным набором фич, и лишь потом её начинают подгонять под неполноценные браузеры и различные альтернативные условия.
а. как правило верстальщик получает от дизайнера макет, на котором страница представлена уже со всеми наворотами, и на выходе требуется результат «на 100% соответствующий макету в современных браузерах».
б. без вдумчивого анализа из макета бывает сложно понять, какие фичи жизненно важны, а какими можно жертвовать.
это только две причины, из-за которых первая версия страницы создается с полным набором фич, и лишь потом её начинают подгонять под неполноценные браузеры и различные альтернативные условия.
описание PrEn разбито на последовательные этапы и поэтому производит впечатление еще и методики разработки. но выполнение таких шагов ещё не дает гарантий для получения ожидаемого результата.
например, на очередном технологическом витке может возникнуть необходимость внести изменения, которые сломают что-то на предыдущих этапах (например — добавить в код html дополнительные теги, которые требуются «навороченной» версии интерфейса),
так же это не всегда оправдано, т.к. нельзя исключать вероятность того, что реализации функциональности на базовом уровне, потребует выполнить какой-то самостоятельный объем работ для обхода технологических ограничений (например, функциональность «добавить еще, и еще одну картинку» при наличии js, тривиально, реализуется в рамках одной страницы, и потребует создавать дополнительные ручки на сервере, с использованием чего-то в роде сессий, REST и т.п. чтобы реализовать то же самое на уровне «чистого» html).
например, на очередном технологическом витке может возникнуть необходимость внести изменения, которые сломают что-то на предыдущих этапах (например — добавить в код html дополнительные теги, которые требуются «навороченной» версии интерфейса),
так же это не всегда оправдано, т.к. нельзя исключать вероятность того, что реализации функциональности на базовом уровне, потребует выполнить какой-то самостоятельный объем работ для обхода технологических ограничений (например, функциональность «добавить еще, и еще одну картинку» при наличии js, тривиально, реализуется в рамках одной страницы, и потребует создавать дополнительные ручки на сервере, с использованием чего-то в роде сессий, REST и т.п. чтобы реализовать то же самое на уровне «чистого» html).
А как вы реализуете отложенную загрузку картинок без JS?
Будете выводить картинки сотнями на каждый запрос? Или будете на сервере проверять юзер-агента каким-то образом?
Как вы реализуете форму, в которой одни поля зависят от значений в других?
Будете выводить совершенно все поля и хитроумно валидировать на сервере?
Вы видите, насколько возрастают трудозатраты на серверный код? Вы сравнивали трудозатраты на прямую CSS3 верстку с JS в сравнении с Progressive Enhancement? Они адекватно соотносятся с числом пользователей без JS и на старых броузерах?
Если вы делаете сайты из любви к веб-технологиям — PE безусловно хорош. Но если вы оцените его эффективность с точки зрения UX и экономически — этот подход родственен перфекционизму. Часто это значит, что вы просто не знаете пользователя, для которого делаете сайт.
Будете выводить картинки сотнями на каждый запрос? Или будете на сервере проверять юзер-агента каким-то образом?
Как вы реализуете форму, в которой одни поля зависят от значений в других?
Будете выводить совершенно все поля и хитроумно валидировать на сервере?
Вы видите, насколько возрастают трудозатраты на серверный код? Вы сравнивали трудозатраты на прямую CSS3 верстку с JS в сравнении с Progressive Enhancement? Они адекватно соотносятся с числом пользователей без JS и на старых броузерах?
Если вы делаете сайты из любви к веб-технологиям — PE безусловно хорош. Но если вы оцените его эффективность с точки зрения UX и экономически — этот подход родственен перфекционизму. Часто это значит, что вы просто не знаете пользователя, для которого делаете сайт.
1. Разобъём вывод картинок на несколько страниц, если их там сотни. Для тех у кого js — подгружать ajax-ом или через lazy load, у кого нет js — постраничная навигация.
2. Приведите пример. Для проверки значения поля можно использовать regexp.
Если сайт представляет из себя javscript-приложение, то тут ничего не поделать (к примеру карты). На обычных же сайтах навигация, ссылки, кнопки и формы должны спокойно работать без js.
2. Приведите пример. Для проверки значения поля можно использовать regexp.
Если сайт представляет из себя javscript-приложение, то тут ничего не поделать (к примеру карты). На обычных же сайтах навигация, ссылки, кнопки и формы должны спокойно работать без js.
1. +1 задача на серверного программиста [и множество бессмысленных URL]
И все-таки предлагаете на сервере определять наличие JS на клиенте и выводить либо пагинированные картинки, либо полную версию?
2. Примеры:
— Разный формат записи адреса в зависимости от выбранной страны;
— Разный вид реквизитов в зависимости от выбранного вида собственности (юр/физ лицо)
— Обычная специализация по дереву категорий (Общество > Развлечения > Праздники > Новый год)
— Выбор файла в дереве
Это все решаемо так или иначе, но трудозатраты очевидны, — а целесообразны ли?
И все-таки предлагаете на сервере определять наличие JS на клиенте и выводить либо пагинированные картинки, либо полную версию?
2. Примеры:
— Разный формат записи адреса в зависимости от выбранной страны;
— Разный вид реквизитов в зависимости от выбранного вида собственности (юр/физ лицо)
— Обычная специализация по дереву категорий (Общество > Развлечения > Праздники > Новый год)
— Выбор файла в дереве
Это все решаемо так или иначе, но трудозатраты очевидны, — а целесообразны ли?
Если сроки позволяют то да. Надо стараться всегда сделать как можно лучше.
Не всегда это значит PE. Как можно лучше — значит доставляет больше профита пользователю/владельцу. Если за поддержку ~1% пользователей на IE6, Opera Mini или с отключенным JS приходится увеличивать объем работ на 10-20% и оплачивать часы специалистам при ограниченном бюджете, то лучше — вероятно, отказаться от PE.
GD гораздо естественнее выглядит с точки зрения процесса разработки: мы первым усилием покрываем основных пользователей, а только затем уже заботимся о маргиналиях.
GD гораздо естественнее выглядит с точки зрения процесса разработки: мы первым усилием покрываем основных пользователей, а только затем уже заботимся о маргиналиях.
Будете выводить совершенно все поля и хитроумно валидировать на сервере?Валидация формы «от и до» на серверной стороне — это необходимость, в любом случае.
Тем не менее остается ряд вопросов.
Во-первых, как выводить форму с зависимыми полями на чистом HTML, — это вытекает в неоднозначность решения. В некоторых случаях, когда это приведет к n-страничной форме, это вызовет батхерт на серверной стороне.
Во-вторых, формировать на сервере отвалидированную форму с ошибками напротив полей не всегда настолько простая задача, как возврат JSON'а типа
В-третьих, хитроумной валидации в некоторых случаях можно избежать. Пример: на сервере используется стандартное решение, а на клиенте вдруг захотелось принимать в поле «представьтесь» не просто какое-то одно слово, а три, типа фамилию, имя и отчество. Такая инвалидность не критична для данных, но валидацией на клиенте это решается элементарно. Т. е. оператору раз в месяц исправить неполное поле от клиента без JS обойдется дешевле, чем оплачивать специалисту время на написание своего валидатора для какого-то стандартного решения.
Во-первых, как выводить форму с зависимыми полями на чистом HTML, — это вытекает в неоднозначность решения. В некоторых случаях, когда это приведет к n-страничной форме, это вызовет батхерт на серверной стороне.
Во-вторых, формировать на сервере отвалидированную форму с ошибками напротив полей не всегда настолько простая задача, как возврат JSON'а типа
field_name : invalid_status. Помножьте это на n страниц формы. В-третьих, хитроумной валидации в некоторых случаях можно избежать. Пример: на сервере используется стандартное решение, а на клиенте вдруг захотелось принимать в поле «представьтесь» не просто какое-то одно слово, а три, типа фамилию, имя и отчество. Такая инвалидность не критична для данных, но валидацией на клиенте это решается элементарно. Т. е. оператору раз в месяц исправить неполное поле от клиента без JS обойдется дешевле, чем оплачивать специалисту время на написание своего валидатора для какого-то стандартного решения.
> Как вы реализуете форму, в которой одни поля зависят от значений в других?
Очевидно Wizard-ом на несколько страниц.
Очевидно Wizard-ом на несколько страниц.
Спасибо за статью!
Есть библиотека для создания веб-интерфейсов Wt, которая позволяет абстрагироваться достаточно, чтобы выбор стратегии (Progressive Enhancement или Graceful Degradation) был опцией в файле конфигурации.
Есть библиотека для создания веб-интерфейсов Wt, которая позволяет абстрагироваться достаточно, чтобы выбор стратегии (Progressive Enhancement или Graceful Degradation) был опцией в файле конфигурации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Progressive Enhancement или всё-таки Graceful Degradation