Пользователь
0,0
рейтинг
2 ноября 2012 в 12:47

Разработка → Progressive Enhancement или всё-таки Graceful Degradation

SerenityНельзя просто так взять и рассказать про progressive enhancement, не упомянув о graceful degradation. В чем же разница между этими понятиями? Как уже говорилось в более ранней статье, graceful degradation можно перевести, как отказоустойчивость. Это очень широкое понятие, но в контексте веба его можно понимать как отказоустойчивость клиентских веб-интерфейсов, серверной части сайтов и так далее. В этой статье graceful degradation будет пониматься как отказоустойчивость клиентских веб-интерфейсов.

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

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

  1. «Старый-добрый-HTML» этап
  2. CSS этап
  3. CSS3 этап
  4. JavaScript этап

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

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

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

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

Резюмируем назначение описанных этапов:

  1. Смысл документа, логическая разметка. Технология: HTML.
  2. Внешний вид. Технология: CSS.
  3. Безупречный внешний вид. Технология: CSS3.
  4. Взаимодействие, интерактивность, удобство. Технология: JavaScript.

Можно сказать, что веб-интерфейс, созданный добросовестно и качественно, в соответствии с подходом graceful degradation, будет вести себя так же, как и веб-интерфейс, построенный в соответствии с progressive enhancement. То есть, progressive enhancement — это не что иное, как graceful degradation, доведенный до совершенства. Всё же отметим ключевые различия этих понятий:

  • Graceful degradation — более широкое понятие, чем progressive enhancement, который ограничен только веб-интерфейсами. Progressive enhancement — это наше, родное, вебовское.
  • Progressive enhancement задает вектор движения (начинай с простого!), а для graceful degradation это не так важно.
  • Progressive enhancement настаивает на важности содержания, а для graceful degradation оно на втором плане.

В общем, progressive enhancement — это более строгая и последовательная идеология разработки веб-интерфейсов.

Почему появился Progressive Enhancement


Ранее говорилось, что если взять и в соответствии с graceful degradation максимально качественно сделать веб-интерфейс, то получится то же самое, что и при применении progressive enhancement. Так зачем же было придумывать этот enhancement?

Ответ прост: мало кто делал graceful degradation очень качественно. Это расстраивало действительно высококлассных и ответственных разработчиков. Ведь сказать, что «я — молодец и делаю graceful degradation» мог почти любой, но затраты сил и времени у разных разработчиков различались на порядки.

В самом простом случае плохого graceful degradation делается сайт для самых современных браузеров, а для устаревших в верхней части страницы добавляется сообщение, что браузер староват. При этом никого не волнует, что будет происходить с сайтом в старом браузере: развалится он или нет, будет виден весь контент или что-то исчезнет. Другой распространенный вариант плохого graceful degradation — интерфейс перестает работать при отключенном JavaScript. Простой пример: попробуйте отправить сообщение во ВКонтакте при отключенном JavaScript.

Короче говоря, такая халтура с отказоустойчивостью порядком надоела «правильным» разработчикам, надо было что-то делать. Progressive enhancement возник как реакция на плохой graceful degradation. Теперь действительно хорошие разработчики и дизайнеры могут делать progressive enhancement, а плохие не могут, так как это сложнее и трудозатратнее. Заодно новый подход впитал в себя все лучшие практики из graceful degradation.

Практический пример


Мы разобрались с тем, что такое progressive enhancement, теперь пришло время на практическом примере продемонстрировать, как этот подход применять в жизни. Разработаем и оформим простую форму авторизации в соответствии с ним.

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



На втором этапе c помощью простейшего CSS сделаем форму красивее: добавим фон, размеры, отступы. Теперь форма выглядит лучше:



На третьем этапе используем некоторые новые CSS свойства, чтобы придать форме блеск. Добавим закругления с помощью border-radius, тени для элементов с помощью box-shadow, используем css-градиенты для оформления кнопки и так далее. Используем некторые продвинутые селекторы, чтобы избавиться от лишних отступов. Результат довольно хорош:



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

На простейшем примере мы показали, как работает подход progressive enhancement. Кстати, данный пример можно «пощупать вживую» в интерактивной демонстрации на htmlacademy.

Чтобы понять, как работает graceful degradation, просто просмотрите шаги в примере в обратном направлении. Возникает вопрос — можно ли для этого примера сделать graceful degradation плохо? Конечно, да! Например, если бы верстальщик размышлял вот так:

Логиниться будем с помощью AJAX, значит с формой заморачиваться не надо, использую div. Круглые уголки и тенюшки… Это проблема. Для полей ввода использую input без границ, а фоном задам картинку с рамкой и тенями. Кнопку сделаю с помощью div, на фон повешу картинку кнопки с градиентом и тенями. Классно! И в старом IE будет красиво смотреться, и всего несколько картинок вырезать.

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

Progressive Enhancement и Responsive Design


В последнее время набирает популярность подход, который называется responsive design, по-русски адаптивный или отзывчивый дизайн. Суть подхода заключается в том, чтобы с помощью определенного набора техник (резиновые сетки, резиновые изображения, CSS media queries) сделать так, чтобы веб-страница адекватно отображалась на различных устройствах: от смартфона до широкоформатного монитора. Это достигается за счет динамического изменения сетки страницы, размеров элементов и так далее.

Одновременно появился похожий подход, который называется mobile first. На русский его название можно перевести, как «сначала для мобильников!». По сути, это тот же адаптивный дизайн, но с обязательным требованием: всегда начинать проектирование адаптивного интерфейса с мобильной версии.

Соотношение подходов responsive design и mobile first очень похоже на соотношение graceful degradation и progressive enhancement. Первый подход в паре общий, а второй подход частный и добавляет к первому дополнительные требования: «начинай с простого html», «начинай проектировать с мобильной версии», «погладь кота».

Стоит отметить, что озвученные подходы отлично сочетаются друг с другом и отлично друг друга дополняют. И в скором будущем все топовые исполнители будут заявлять: «Мы делаем mobile first + progressive enhancement».



К сожалению, у meritt, автора статьи, не достаточно кармы, поэтому все минусы и плюсы можно адресовать ему.
Mexos @Mexos
карма
31,4
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (49)

  • +8
    Если бы каждый разработчик думал о том как себя будет вести сайт без javascript…
    • +24
      Возможно, сейчас я получу лучи добра и жесткий слив, но сейчас сложно представить себе типичного пользователя без js. Стоит ли тратить время на заботу о пользователе без js — вопрос сложный и зависит от многих факторов.
      Плохо ли это? Да, пожалуй плохо. Забочусь ли я о таких пользователях постоянно (т.е. от проекта к проекту)? Ответ — нет.
      • +4
        Тут идея такая. Сначала пишется простейший базовый функцинал, который не нуждается в js. А следующим слоем он расширяется с помощью js. Где тут дополнительные затраты времени? Всё равно придется писать всю ту же логику на js, что и обычно.
        • 0
          Да тут особо спорить не о чем. Это же все индивидуально от проекта к проекту, как мне кажется. Например — отправка формы в фоне: конечно у формы есть action и если js у пользователя не включен, то форма просто отправится «естественным образом». Но тут забота о пользователе проявляется постольку-поскольку. Как вы уже сказали: базовый функционал и так есть. Или к примеру карусель изображений ( типа jcarousel, JQuery Cycle и т.д.) изображения и так выводятся и если не включен js, то они будут показаны и можно даже облагородить их вывод.
          А вот другой пример: fancybox. Нужно по клику куда-либо показать окошко с информацией. И нет js. Как быть? Очевидного решения я не вижу, такого что б совсем без затрат времени.

          Прошу прощения если примеры вдруг показались вам наивными. Первое, что пришло в голову.
          • –2
            Значит надо спроектировать интерфейс так чтобы js не потребовался. Если нужно показать картинку в полном размере — пожалуйста, прямая ссылка.

            И вообще верстальщик и дизайнер всегда должны задавать себе вопросы: а что если пользователь не загрузил js, css или картинки? Как будет выглядеть такой сайт?

            Только такой подход считаю правильным.
            • +2
              Ну с картинками — вопрос простой. Нет обработчика — переход по ссылке.

              А вот, например, авторизация через соц. сети?

              Вы не подумайте что я рву майку за обязательное наличие js. Я просто веду к тому, что тут вопрос довольно «интимный» и зависит как от заказчика так и от исполнителя и даже от аудитории сайта, как мне кажется. Просто в каждом случае нужно подходить индивидуально. Что, конечно же ни как не идет в разрез с общими правилами «хорошего тона» по типу нет js — переходим по ссылке и т.д. Это же очевидно, как по мне.
              • 0
                Авторизация через соц. сети это другой вопрос (она идёт как бы бонусом), но своя авторизация точно должна спокойно работать без javascript.
                • 0
                  Ну, это понятно. Я выше писал про action у форм.
              • +2
                А вот, например, авторизация через соц. сети?

                Что касается авторизации в соц. сетях, то она как раз отлично работает и без js.

                Есть класс сайтов, в которых основной составляющей является именно js, взять те же Яндекс.Карты и сервисы, их использующие или тот же htmlacademy. На подобных проектах очень сложно сделать что-то внятное без js.

                Остальные же сайты, на которых js не слишком сложный и его не слишком много, должны делаться с заботой о содержании, а потом уже с заботой о рюшечках. Это, конечно, личное дело каждого, но по таким мелочам виден профессиональный уровень и любовь к своему делу =)
                • +1
                  Что касается авторизации в соц. сетях, то она как раз отлично работает и без js.


                  Если я не ошибаюсь, то мы говорим о дополнительных затратах:
                  Где тут дополнительные затраты времени? Всё равно придется писать всю ту же логику на js, что и обычно.


                  И это как раз случай дополнительных трудозатрат. Не так ли?
            • +1
              а что если пользователь не загрузил js, css или картинки? Как будет выглядеть такой сайт?

              Паршиво :)
          • 0
            Нужно по клику куда-либо показать окошко с информацией. И нет js. Как быть? Очевидного решения я не вижу, такого что б совсем без затрат времени.


            Если информация уже на страничке, но спрятана, то просто без JS диалог не прячется и располагается где-то под подвалом. Кнопка вызова диалога должна иметь реальную локальную ссылку (#fancybox). После надатия на такую кнопку без JS пользователь будет переброшен к нужной ниформации или форме ввода.

            Если информация не присутствует на странице, то лучше всего её хранить по какому нибудь адресу (REST наше всё). После щелчка по кнопке (ссылке) без JS мы переходим по адресу с веб-формой или информацией. Если JS есть, то веб-форма или информация подкачивается и вставляется в страничку.
      • +2
        Лично для себя я нахожу три причины почему сайт должен работать без js:
        1. Так изначально задуман вэб, javascript добавляет интерактивность и лишь безболезненно расширяет базовый функционал заложенный в html, но не заменяет собой такие базовые вещи как URI и сайт должен работать нормально и без javascript.
        2. Поисковики. Да, гугл бот научился распознавать javascript, но такая индексация занимает три дня (недавно была статья), не все поисковые боты такие умные.
        3. Opera Mini.

        Может я старомодный в этом плане, но когда я вижу сайты которые работают без javascript а с ним лишь получают дополнительный user experience — хочется пожать разработчику руку.
        Один из хороших примеров здесь это форумный движок XenForo. Очень грамотная реализация этой идеи. (особое внимание на ajax)
      • –7
        Если сайт приносит недостаточно пользы, чтобы оправдать добавление исключения в NoScript, такой сайт идет лесом.

        Почему NoScript? Потому что безопасность + по умолчанию отсутствие раздражающих сюрпризов вроде ненужных музыки/флэша/снежинок и т.д.
        • 0
          Часто вас через javascript ломают?
          Умеет ли НоСкрипт блокировать HTML Audio? (Я просто не знаю).
      • 0
        Что ж, пользуясь случаем, хочу «поблагодарить» всех программистов, которые придерживаются подобного подхода.

        Благодаря таким как вы, например, на сайте РЖД невозможно посмотреть наличие билетов в Opera Mini (с чем я столкнулся не далее, чем сегодня).

        Давайте, продолжайте в том же духе, зачем напрягаться? Пипл хавает.
      • +1
        Возможно, сейчас я получу лучи добра и жесткий слив, но сейчас сложно представить себе типичного пользователя без js.

        Всё просто:
        — Представьте google (yandex, whatever) бота
        — представьте функциональное авто-тестирование своим краулером (с behat например)

        Да есть много краулеров поддерживающих JS, но они не так просты, надежны, быстры. Впрочем как порой и JS функционал в отсутствие системы описанной в статье.
        • 0
          С тестирование не совсем понял. Если мне нужно тестировать фронтенд, то какой мне толк от того, что у меня все работает без js (и оттестировано), если моя аудитория на 90% состоит из клиентов с js.
          Я чего-то не так понял?

          сложно представить себе типичного пользователя без js.


          представьте функциональное авто-тестирование своим краулером (с behat например)

          Мы сейчас об одних и тех же «типичных пользователях» говорим?
          • 0
            Краулеры тоже «пользователи», и если SEO у вас не на последнем месте, то такие же VI«P» как и остальные.

            А с тестированием так: вы можете тестировать JS функционал селениумом. Вопрос — надо ли это делать in the first place. Обычно JS-причиндалы это только маленькая вершинка айсберга. Ну если только у вас не все приложение — джаваскриптовый айсберг, что значит или вы работаете в гугл, или вы что-то овер-инжинирите. Бо´льшая часть большинства проектов легко тестируется обычным get/post краулером, и JS в этих проектах для простоты рассчитывает (и фолбэкается на) те же самые get/post. Только тесты проверяющие JS =on режим будут выполняться часами, а не минутами.

            Даже если аудитория на 99% состоит из клиентов с JS, это девелоперу же лучше сводить любые процессы к простым легко-тестируемые и, соответственно, легко-дебажным механизмам (a href, onsubmit, post, get), по сравнению с запутанными коллбэками с трудновоспроизводимыми кейсами «кликни тут, тут и тут, смотри вывод стектрейса в файербаге, сделай изменение в коде, повтори всё снова».
            • 0
              Если говорить о POST/GET и href — то об этом уже писалось выше, и мной в том числе, что оставлять прямой url у ссылки и action у формы сами собой разумеющиеся вещи (для меня по крайней мере). Но в общем-то я понял к чему вы.

              Опять таки, мы пришли к тому, с чего начинали. Все зависит от проекта.
        • 0
          Google Bot уже умеет исполнять JavaScript. Скоро и остальные подтянутся.
    • +3
      Вот например, мобильный хабр отвратительно работает с JS.
      Медленный интерфейс, если набирать ответ, буквы появляются по одной (зачем перехватывать ввод?..)
      Иногда возникают неприятные глюки:
      Скрытый текст

      А если JS отключить, то страница ведет себя как и положено — очень шустро. Правда, не работает отправка комментариев и нельзя голосовать…

      (В саппорт писал, даже несколько раз — бесполезно, говорят, проблема только у меня)
  • 0
    Так Pogressive Enhancement или всё-таки Graceful Degradation?

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

    И засилье англицизмов очень режет взгляд, хоть я и привык уже бегло читать на английском. Большинство же — даже на хабре — английский не знает или знает плохо.
    • 0
      Ссори, а это перевод что ли? Если да, то можно ссылочку на оригинал плз?)
    • +1
      Когда вы с помощью картинок делаете кнопку такой же красивой в старых браузерах (из-за фирменного стиля или просто требования заказчика) — это уже изящная деградация

      Нет.

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

      Пример: картинки с Lightbox.
      Изящная деградация — это возможность увидеть увеличенный размер картинки, пройдя по прямой ссылке, если по какой-то причине js событие для загрузки Lightbox не сработало.
      • 0
        Пример понятен. Почему вы ограничиваете отключением фич непонятно. Впрочем и в моём примере ограничивается возможность масштабирования, так как растровые картинки масштабируются хуже эффектов CSS-свойств.
  • +1
    Graceful Degradation — это не совсем отказоустойчивость.

    Основной смысл в том, что сайт работает хорошо, красиво и быстро в последних версиях браузеров, хорошо и красиво/быстро в устаревших и просто как-то работает в древних.
    Т.е. там основной упор на то, что чем старее браузер — тем хуже выглядит и работает сайт, но работает.

    Т.е. мы делаем современный сайт, со всеми модными фишками, но который будет работать и без них (ненавязчивый js, например).

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

    Здесь с автором не соглашусь в плане «сложнее и трудозатратнее». Писать сначала разметку, потом добавлять оформление и поведение — на мой взгляд, это не сложнее. И более того — приятнее, мне лично доставляет удовольствие размечать документ чистым HTML, думать как поддержать семантику документа, какой тег уместнее и т. д. Если какой-то верстальщик не любит этого делать, то у меня для него плохие новости. В итоге же прогрессивное улучшение не трудозатратнее, ведь пытаясь соблюсти принципы изящной деградации, вы в принципе делаете то же самое — обеспечиваете функциональность в старых браузерах. Я бы даже сказал, что оба подхода в идеале суть одно и то же, разница в том, когда вы начинаете думать о том, как это будет выглядеть в IE6 или на старом телефоне, — сразу или после того, как напишете CSS3 и JS.
  • +4
    Это, конечно, здорово, но на дворе конец 2012-го, сейчас уже даже ddos по javascript фильтруют (nginx testcookie, например), есть ли смысл тратить ресурсы на устаревших клиентов?
  • +2
    Мне кажется, здесь размыто понятие «веб-интерфейс» между интерфейсом одностраничных веб-приложения (RIA), где HTML-документ как основа приложения уже не подходит, и интерфейсом веб-сайта, форума, блога, где HTML-документ наиболее подходит в качестве основы.

    Для первых «gracefull degradation» в части случаев невозможна в принципе из-за необходимости всего стека доступных технологий для предоставления функций веб-приложения, а в другой части может иметь вид разве что отдельно разработанного с нуля упрощенного интерфейса (пример — почтовые веб-клиенты, где можно привести работу с почтой как работу с HTML-документами).

    Для вторых эта концепция действительно имеет место быть в полном объеме: посетителю предоставляется контент, а не функциональность.

    Многие пытаются объединить эти две несовместимых области (например, проект jQuery UI), и это запутывает.
  • +2
    В целом, да, примерно так и надо. С другой стороны, на умеренно-загруженном сайте у нас за 3 месяца было ровно 2 пользователя без js, около 40 на старых ie и около 40000 всех остальных. Какой смысл?
    Я за то, чтобы сайты были правильно размечены и радикально против того, чтобы с помощью JS затыкать дыры верстки — но жертвовать ради совместимости, например, плейсхолдерами — да ну в пень такую совместимость.
    • 0
      А зачем чем-то жертвовать? Писать html и js можно без всяких жертв.
  • +1
    мне кажется, что корни GrDe можно поискать еще и в процессах разработки.
    а. как правило верстальщик получает от дизайнера макет, на котором страница представлена уже со всеми наворотами, и на выходе требуется результат «на 100% соответствующий макету в современных браузерах».
    б. без вдумчивого анализа из макета бывает сложно понять, какие фичи жизненно важны, а какими можно жертвовать.

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

    например, на очередном технологическом витке может возникнуть необходимость внести изменения, которые сломают что-то на предыдущих этапах (например — добавить в код html дополнительные теги, которые требуются «навороченной» версии интерфейса),

    так же это не всегда оправдано, т.к. нельзя исключать вероятность того, что реализации функциональности на базовом уровне, потребует выполнить какой-то самостоятельный объем работ для обхода технологических ограничений (например, функциональность «добавить еще, и еще одну картинку» при наличии js, тривиально, реализуется в рамках одной страницы, и потребует создавать дополнительные ручки на сервере, с использованием чего-то в роде сессий, REST и т.п. чтобы реализовать то же самое на уровне «чистого» html).
  • 0
    А как вы реализуете отложенную загрузку картинок без JS?
    Будете выводить картинки сотнями на каждый запрос? Или будете на сервере проверять юзер-агента каким-то образом?

    Как вы реализуете форму, в которой одни поля зависят от значений в других?
    Будете выводить совершенно все поля и хитроумно валидировать на сервере?

    Вы видите, насколько возрастают трудозатраты на серверный код? Вы сравнивали трудозатраты на прямую CSS3 верстку с JS в сравнении с Progressive Enhancement? Они адекватно соотносятся с числом пользователей без JS и на старых броузерах?

    Если вы делаете сайты из любви к веб-технологиям — PE безусловно хорош. Но если вы оцените его эффективность с точки зрения UX и экономически — этот подход родственен перфекционизму. Часто это значит, что вы просто не знаете пользователя, для которого делаете сайт.
    • +1
      1. Разобъём вывод картинок на несколько страниц, если их там сотни. Для тех у кого js — подгружать ajax-ом или через lazy load, у кого нет js — постраничная навигация.

      2. Приведите пример. Для проверки значения поля можно использовать regexp.

      Если сайт представляет из себя javscript-приложение, то тут ничего не поделать (к примеру карты). На обычных же сайтах навигация, ссылки, кнопки и формы должны спокойно работать без js.
      • 0
        1. +1 задача на серверного программиста [и множество бессмысленных URL]
        И все-таки предлагаете на сервере определять наличие JS на клиенте и выводить либо пагинированные картинки, либо полную версию?
        2. Примеры:
        — Разный формат записи адреса в зависимости от выбранной страны;
        — Разный вид реквизитов в зависимости от выбранного вида собственности (юр/физ лицо)
        — Обычная специализация по дереву категорий (Общество > Развлечения > Праздники > Новый год)
        — Выбор файла в дереве

        Это все решаемо так или иначе, но трудозатраты очевидны, — а целесообразны ли?
        • +1
          Если сроки позволяют то да. Надо стараться всегда сделать как можно лучше.
          • 0
            Не всегда это значит PE. Как можно лучше — значит доставляет больше профита пользователю/владельцу. Если за поддержку ~1% пользователей на IE6, Opera Mini или с отключенным JS приходится увеличивать объем работ на 10-20% и оплачивать часы специалистам при ограниченном бюджете, то лучше — вероятно, отказаться от PE.
            GD гораздо естественнее выглядит с точки зрения процесса разработки: мы первым усилием покрываем основных пользователей, а только затем уже заботимся о маргиналиях.
    • +1
      Будете выводить совершенно все поля и хитроумно валидировать на сервере?
      Валидация формы «от и до» на серверной стороне — это необходимость, в любом случае.
      • 0
        Тем не менее остается ряд вопросов.
        Во-первых, как выводить форму с зависимыми полями на чистом HTML, — это вытекает в неоднозначность решения. В некоторых случаях, когда это приведет к n-страничной форме, это вызовет батхерт на серверной стороне.
        Во-вторых, формировать на сервере отвалидированную форму с ошибками напротив полей не всегда настолько простая задача, как возврат JSON'а типа field_name : invalid_status. Помножьте это на n страниц формы.
        В-третьих, хитроумной валидации в некоторых случаях можно избежать. Пример: на сервере используется стандартное решение, а на клиенте вдруг захотелось принимать в поле «представьтесь» не просто какое-то одно слово, а три, типа фамилию, имя и отчество. Такая инвалидность не критична для данных, но валидацией на клиенте это решается элементарно. Т. е. оператору раз в месяц исправить неполное поле от клиента без JS обойдется дешевле, чем оплачивать специалисту время на написание своего валидатора для какого-то стандартного решения.
        • 0
          Если фронтенд вызывает баттхёрт у бэкэнда то это проблема серверной стороны, он вообще должен адекватно реагировать на любой post-запрос, иначе пара школьников вмиг положат такой сервис.
          • 0
            Я не до конца понимаю вашей позиции — что вы пытаетесь донести? Что PE — хорошо? Тогда контраргументируйте как-то хотя-бы.
    • 0
      > Как вы реализуете форму, в которой одни поля зависят от значений в других?

      Очевидно Wizard-ом на несколько страниц.
  • 0
    Спасибо за статью!

    Есть библиотека для создания веб-интерфейсов Wt, которая позволяет абстрагироваться достаточно, чтобы выбор стратегии (Progressive Enhancement или Graceful Degradation) был опцией в файле конфигурации.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.