Так ли дорого прогрессивное улучшение
- 14 января 2013
В предыдущей статье рассматривалась теория и практика прогрессивного улучшения (progressive enhancement). В этой статье мы от идеологии перейдём к аксиологии и рассмотрим финансово-экономическую обоснованность применения прогрессивного улучшения.
В некоторых комментариях к предыдущей статье выражалось мнение, что использовать прогрессивное улучшение в реальной разработке не стоит. Причины сводились к излишней дороговизне: «На то, чтобы создать сайт в соответствии с этим подходом, нужно потратить слишком много времени, а это слишком дорого и не нужно ни заказчику (за такие деньги), ни исполнителю».
Так как весь вопрос, как обычно, во временных затратах и стоимости, то в этой статье мы рассмотрим «прогрессивное улучшение vs обычная разработка» с точки зрения дополнительных временных затрат. Как и в предыдущей статье, делать это будем поэтапно.
«Старый-добрый-HTML»
На этом этапе верстальщик создаёт логичную и семантически правильную HTML-разметку без использования CSS. Никаких дополнительных временных затрат на этом этапе не возникает. Естественно, некоторым верстальщикам удобнее создавать HTML-код и одновременно набрасывать стили. Прогрессивное улучшение не запрещает этого: пожалуйста, пишите и стили, но сначала уделите пристальное внимание разметке.
Есть небольшая, но важная деталь: необходимо думать и о правильном порядке кода, чтобы страница без стилей выглядела логично. Например: если важно, чтобы телефон был в верхней части страницы, то и в коде он должен быть в начале, а не в конце. Ведь иногда телефон, находящийся в макете в правой колонке, запихивают в блок HTML-кода, находящийся ближе к концу файла. Без стилей такой телефон окажется далеко-далеко.
«CSS»
Важное замечание: прогрессивное улучшение не имеет ничего общего с вёрсткой под Internet Explorer 6. вёрстка под IE6 — который не просто не поддерживает стандарты, а поддерживает их неправильно — это отдельная задача, которая у многих исполнителей так и называется — «вёрстка под IE6» и оценивается дополнительно. Таким образом, поддержка IE6 вносит дополнительные затраты при любом подходе. Если клиент хочет заплатить за это — пожалуйста, а если нет, то и не надо ему это втюхивать.
Для тех, кто настаивает на поддержке IE6, приведу аналог с кодировками. Раньше создавалось несколько версий сайта, заточенных под разные кодировки, например, KOI8-R и Windows-1251. Сейчас так уже не делают, хотя, при желании можно раскопать и запустить Очень Старый Компьютер с Очень Старой Виндовс. Так может быть уже пора забыть IE6 как страшный сон?
Что касается других старых браузеров, которые корректно поддерживают CSS2, то в них сайт будет смотреться прилично. Под старинный Firefox 3 в далёком 2008 году верстать было легко и приятно.
Итак, прогрессивное улучшение не вносит дополнительных временных затрат на втором этапе. Действительно, задача создать сетку страницы и простое оформление с использованием возможностей CSS2 для опытного верстальщика тривиальна, какой бы подход он ни использовал.
«CSS3»
Важное замечание: прогрессивное улучшение не требует, чтобы сайт одинаково хорошо отображался во всех браузерах. Даже наоборот — сайт должен отображаться в браузере адекватно его возможностям. Не умеет браузер уголки рисовать — ничего страшного, будут квадратные уголки. Прогрессивное улучшение очень прагматично в этом подходе.
Согласитесь, такой подход очень практичен. Мы уже позаботились об аккуратном отображении интерфейса на предыдущем этапе. А на этом этапе мы постепенно делаем интерфейс красивее для тех браузеров, где поддерживаются новые свойства. При минимальных затратах сил и времени. Это означает, что можно забыть о вырезании кучки.png файлов для уголков и теней, о куче вложенных дивов и тоннах излишней разметки.
Все это ведёт к огромной экономии времени. И как бонус — верстальщик начинает получать удовольствие от работы, потому что избавляется от рутины и одновременно получает простор для творчества и экспериментов. Ведь сэкономленное время можно тратить на другие проекты, а можно и экспериментировать с новейшими свойствами на текущем проекте, добавляя wow-фичи для пользователей новых браузеров.
Подведём итог: на третьем этапе прогрессивное улучшение даёт существенную экономию времени разработчика.
«JavaScript»
Этот этап самый спорный и самый интересный, поэтому на нём остановимся более подробно и разберём несколько практических примеров.
Вначале небольшая оговорка: мы не будем рассматривать сайты, работа которых без JavaScript в принципе невозможна или теряет всякий смысл, например: HTML Academy, различные онлайн-редакторы и так далее.
В целом, можно сказать, что при грамотном подходе дополнительные затраты времени на этом этапе есть, но они небольшие. В основном, они сводятся к усложнению инициализации скриптов. Иногда дополнительные затраты могут быть существенными, так как происходит усложнение не только на клиенте, но и на сервере.
Различные ситуации, возникающие на этом этапе, лучше разбирать на практических примерах.
Пример 1. Форма «Заказать звонок»
Задача: «На каждой странице сайта есть ссылка „Заказать звонок“, при щелчке на которую всплывает форма обратного звонка с оверлеем».
Задача была решена в соответствии с прогрессивным улучшением следующим образом:
- HTML-код формы находится внутри кода страницы.
- С помощью CSS делается простейший эффект появления формы: изначально форма скрыта, видна только ссылка «обратный звонок». При наведении на ссылку появляется абсолютно позиционированная форма.
- С помощью JavaScript на форму добавляются дополнительные классы, с помощью которых меняется логика отображения. Также усовершенствуется поведение формы, механизм позиционирования, добавляется оверлей.
Что мы получили в итоге? Форма существует в теле страницы и всегда доступна в «голом-HTML-режиме». При наличии CSS форма спрятана, не ломает сетку и умеет отображаться при наведении. Реализация такого поведения на чистом CSS имеет свои минусы, но форма остаётся доступной. С помощью JavaScript отображение и поведение формы приводится к желаемому идеалу.
Дополнительные временные затраты в данном примере минимальны. К необходимой JavaScript-логике нужно дополнительно добавить навешивание дополнительных классов на форму и добавление в HTML-кода для оверлея. Это и есть то самое усложнение инициализации скрипта.
Пример 2. Форма поиска отелей
Этот пример описан в посте про Graceful Degradation. Задача заключалась в том, чтобы сделать форму поиска отелей работающей без JavaScript. Для этого пришлось дорабатывать не только клиентскую часть, но и усложнять серверную. Сервер научился отличать запросы на подгрузку локаций от поисковых запросов.
В этом примере дополнительные временные затраты уже более существенны. В общей сложности они составили примерно рабочий день. Оправданы ли они? Отметим два момента:
- Важность формы. Работа с сайтом практически всегда начинается с поиска отеля.
- Важность фильтрации по месторасположению: отели часто ищут в конкретном городе или даже в конкретном районе.
Таким образом, форма поиска и фильтрация по месторасположению относятся к базовому, необходимому функционалу. А значит, в этом случае дополнительные затраты были оправданы.
Пример 3. Конструктор пиццы
Задача заключается в том, чтобы сделать сайт, на котором можно заказать себе пиццу. Причём пиццу можно заказывать как в «изначальной комплектации», так и в изменённой: выбирать тесто, менять соус, добавлять добавки. Доработка пиццы производится в специальном конструкторе.
Задача была решена в соответствии с прогрессивным улучшением следующим образом:
- При щелчке на ссылку «Заказать онлайн» в корзину добавляется пицца в исходном варианте.
- Если JavaScript работает, то при щелчке на ссылку появляется конструктор, в котором можно выбрать тесто, соус, добавки, после чего уже доработанную пиццу можно добавить в корзину. Вот примеры интерфейса:

При таком решении, как вы заметили, доработка пиццы с помощью конструктора возможна только при работающем JavaScript. Сделать этот же конструктор работающим без JavaScript будет достаточно долго и дорого. А стоит ли? В этом случае, скорее всего, не стоит, потому что:
- Базовым функционалом для подобных сайтов является возможность положить в корзину понравившуюся пиццу. После оформления заказа клиенту перезванивает оператор, который уточняет детали заказа, доставки и т. д. То есть клиент всегда может «оттюнинговать» свою пиццу с помощью оператора.
- JavaScript отключён у малого процента пользователей, а подобный функционал будет достаточно дорог и затянет сроки (и другие типовые аргументы против прогрессивного улучшения).
Как видите, и в рамках прогрессивного улучшения можно отказываться от реализации дополнительного функционала на «чистом HTML», что сэкономит и время, и деньги.
Но! Если вдруг заказчик посчитает конструктор критичным и захочет, чтобы он работал и без JavaScript? Это всегда можно сделать за дополнительную оплату. Ключевой момент заключается в том, чтобы не включать стоимость таких доработок в изначальную оценку.
Вывод по примеру: прогрессивное улучшение надо применять грамотно, без фанатизма. Если появляются серьёзные дополнительные затраты, то пусть они появляются по осознанной воле клиента, а не по глупости разработчика. Или, проще говоря, не надо втюхивать эти дополнительные затраты клиенту только потому, что «так вроде правильно по прогрессивному улучшению».
Подведём итог: на четвёртом этапе прогрессивное улучшение в большинстве случаев приводит к незначительным дополнительным временным затратам. В некоторых случаях затраты существенны. Ещё раз подчеркнём, что прогрессивное улучшение требует, чтобы всегда был доступен только базовый функционал. А реализовать базовый функционал без JavaScript в большинстве случаев не так затратно.
Итого
Дополнительные временные затраты при применении прогрессивного улучшения на каждом из этапов:
- HTML этап — отсутствуют;
- CSS этап — отсутствуют;
- CSS3 этап — экономия времени;
- JavaScript этап — присутствуют, но незначительные.
Незначительные затраты на этапе скриптования с лихвой компенсируются экономией времени на этапе вёрстки. В итоге мы получаем экономию времени, а не дополнительные издержки.
Однако, чтобы прогрессивное улучшение работало эффективно, необходимо наличие двух условий:
- Высокая квалификация и опыт разработчиков. Нельзя с первого раза сделать все быстро и качественно. Сначала нужна практика. Но ведь и применять ООП в PHP все тоже долго и мучительно учились.
- И заказчик, и разработчик должны смириться с тем фактом, что сайт в некоторых браузерах, особенно старых, будет выглядеть «хуже» (а в IE6 даже разваливаться).
Вывод: прогрессивное улучшение — это хороший прагматичный подход, который позволяет разрабатывать интерфейсы быстрее и качественнее. И ничего общего с перфекционизмом прогрессивное улучшение не имеет.
В заключение о грустном
Почему многие студии считают, что прогрессивное улучшение делает разработку слишком долгой и слишком дорогой, а поэтому ненужной клиентам? В большинстве случаев это происходит из-за нехватки квалифицированных разработчиков, которые не понимают сути подхода и не умеют его применять.
Проблема с кадрами на рынке остра. Трудно найти хорошего программиста, но и хороший верстальщик — рыба очень редкая. Взяться им особо неоткуда, так как даже в ведущих ИТ-вузах страны хороших верстальщиков не готовят, да и не ставят себе такую цель. Есть надежда, что новые ФГОСы с их компетентностным подходом и ориентацией на рынок помогут улучшить ситуацию. А пока — остаётся выращивать хороших специалистов самим.
✔ ✅ ❌ ❓🔥🕸💭🏝🔮🖌🚀💽🎓📚🚶♂️⚡👉👆🛠🧂😞🐈⚠️🧬🏗🚶♂️⭐💫💡📖📹💚💬🙂📎
«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.
Читать дальше

Зачем нужен метатег viewport
Каждый из нас хоть раз в жизни сталкивался с веб-страницами, которые кажутся «сломанными» или странно отображаются на мобильных устройствах. Одной из причин такого поведения может быть отсутствие маленького, но важного элемента в коде страницы — метатега viewport
.
Метатеги — это инструкции для браузера о том, как отображать содержимое страницы. Один из таких метатегов — viewport
, который говорит браузеру, как масштабировать и отображать страницу на разных устройствах, особенно на смартфонах и планшетах.
- 18 сентября 2023

Атрибут class в HTML на примерах
Атрибут class
используется для добавления CSS-классов элементам HTML. Классы позволяют применять одни и те же стили CSS или поведение JavaScript к разным элементам на странице.
Так, одному элементу можно присвоить один или несколько классов, разделяя их пробелами.
<!-- Один класс -->
<div class="container">
<!-- ... -->
</div>
<!-- Несколько классов -->
<div class="container special-box">
<!-- ... -->
</div>
- 14 сентября 2023

В чём отличия цитат blockquote, cite и q
В HTML есть разные теги для цитирования и указания источников. Основные из них: <blockquote>
, <cite>
и <q>
. Давайте разберёмся в их различиях.
- 12 сентября 2023

Осмысленный alt-текст: 6 правил
Альтернативный текст — это описание изображения словами. Это описание должно помогать людям, которые читают или слышат это описание, иначе оно не нужно и лучше вообще его не указывать.
Мы уже обсудили основные правила написания alt-текста для фотографий и изображений. В этот раз поговорим о том, каким именно должно быть описание, чтобы в нём был смысл.
- 31 июля 2023

Растровая и векторная графика
Давайте попробуем разобраться, в чём отличие растровой графики от векторной.
- 13 июня 2023

Как понять, что перед вами заголовок
Заголовки используются для организации и структурирования содержимого на сайте. В HTML существует шесть уровней заголовков, обозначаемых тегами от <h1>
до <h6>
. Каждый уровень заголовка имеет свой семантический вес, где <h1>
имеет наибольший вес, а <h6>
— наименьший.
Часто кажется, что заголовок — это простой и понятный тег. Но это впечатление обманчиво, потому что не всегда крупный и выделенный текст на макете является заголовком.
При вёрстке сайта важно соблюдать семантику, чтобы все теги использовались корректно и ресурс работал без ошибок. Если напутать уровни заголовков, то структура страницы будет не семантичной, а скринридеры неправильно прочтут сайт.
В статье разберёмся, как верно определять заголовки по макету, какие из них лучше делать скрытыми и почему.
- 8 июня 2023

Как правильно вставлять SVG
Есть несколько способов вставки SVG-изображения. Выбор одного из них зависит от задач, которые стоят перед верстальщиком.
SVG — это формат векторной графики, дословно: масштабируемая векторная графика. МВГ? SVG! В векторных форматах хранится не само изображение, а инструкция по его построению по точкам и кривым.
В растровых форматах информация о конкретном числе точек изображения плотно упакована в бинарный кирпич. В него бесполезно заглядывать и менять его можно только в редакторах графики.
�PNG
IH�aV
PLTE�������0�
IDAcZ�d���� �W=
S�3�o;���]P
���IEND�B`�~
Формат SVG тоже можно создавать и менять в редакторах графики, например, в Illustrator или Figma. Но ещё он текстовый, а значит его можно открыть как HTML или CSS в любом редакторе кода.
<svg width="20">
<rect fill="#fc0"
width="20"
height="20"/>
<line stroke="black"
x1="0" y1="0"
x2="20" y2="20"/>
</svg>
SVG — это как отдельная HTML-страница. Когда вставляете SVG, вы, на самом деле, вставляете не просто картинку, а целую страницу. Со своей системой координат, вьюпортом, стилями, скриптами и удивительными особенностями.
Если смотреть на SVG как на отдельную страницу — становится понятнее, какой способ вставки вам нужен.
- 1 июня 2023

Как создавать адаптивные изображения. Атрибут srcset
Адаптивные изображения автоматически изменяют свой размер, чтобы соответствовать экрану пользователя, что улучшает вид страницы и ускоряет загрузку.
Давайте рассмотрим несколько способов создания адаптивных изображений.
🎓 В статье мы говорим о пикселях и ретина-дисплеях. Если вы не знаете, что это такое — прочитайте статью.
- 25 мая 2023

В чём разница между <p> и <br>
Чтобы разметить текст, нужно понимать, какие использовать теги. Для создания новой строки в тексте есть несколько способов. В статье мы расскажем, как ими пользоваться.
- 24 мая 2023

Как сделать таблицу в HTML
<table>
— один из основных элементов HTML, который используют для отображения данных (текста, изображения или другого элемента) в ячейках на странице. Таблица состоит из строк и столбцов.
Основные теги, используемые при создании таблицы:
<table>
— определяет начало и конец таблицы. Всё содержимое таблицы должно находиться между<table></table>
.<thead>
— определяет заголовок таблицы. Заголовок может содержать одну или несколько строк, в которых могут использоваться теги<th>
для определения заголовков столбцов.<tbody>
— определяет тело таблицы. Тело содержит одну или несколько строк, в которых могут использоваться теги<td>
для определения содержимого ячеек.<tfoot>
— определяет нижний колонтитул таблицы. Колонтитул может содержать одну или несколько строк, в которых могут использоваться теги<td>
для определения содержимого ячеек.<tr>
— определяет строку таблицы. Каждая строка должна находиться между тегами<tbody>
,<thead>
или<tfoot>
.<th>
— определяет заголовок столбца или строки таблицы. Используется внутри тегов<thead>
и<tr>
.<td>
— определяет содержимое ячейки таблицы. Используется внутри тегов<tbody>
,<tfoot>
и<tr>
.<caption>
— определяет заголовок таблицы, который будет размещен над таблицей. Используется внутри тега<table>
.
- 16 мая 2023