PLAYFACES™ proposal

05-adaptive-strategy

время чтения ~4 мин.

Адаптивная стратегия: два макета вместо десяти

Проблема

В Figma-макете присутствуют до 10 брейкпоинтов: 375, 390, 430, 712, 744, 1024, 1280, 1512, 1728, 2560. По факту это рабочие исследования дизайнера, а не production-состояния. Верстать все — дорого и не имеет смысла.

Решение — Scale-адаптив

Верстаются только два базовых макета — mobile и desktop. Между ними сайт плавно масштабируется пропорционально ширине окна. На 4K — крупнее, на iPad — чуть меньше, на iPhone — в мобильной раскладке.

Что значит «масштабируется пропорционально»

Проще всего показать на живом примере. Открыть non-objective.works и потянуть окно браузера за край — сделать его уже, потом шире.

Обратите внимание: элементы не перепрыгивают на новые позиции, композиция не перестраивается. Всё просто плавно растёт и сжимается вместе с окном: заголовки, картинки, отступы, кнопки. На узком экране шрифт меньше, на широком — больше, но пропорции между элементами одинаковые всегда. Сайт выглядит «как в макете, только другого размера».

Это противоположность классическому адаптиву. В классике макет нарисован отдельно для 1280, отдельно для 1512, отдельно для 1728 — и на каждой ширине элементы «перепрыгивают» по новой сетке. Дорого в вёрстке и не всегда нужно.

(Сайт non-objective.works собран на Readymag, а не через наш Tailwind-плагин — но визуальный принцип тот же самый.)

В случае PLAYFACES добавляется одно переключение — на мобильной ширине (до 1024px) горизонтальный десктопный layout сменяется вертикальным мобильным. На всех остальных ширинах (1024px и выше) — плавный scale, как в примере выше.

Как это выглядит на практике

В Figma остаются два канонических макета:

  • Mobile-макет: базовая ширина 430px (iPhone 15 Pro Max)
  • Desktop-макет: базовая ширина 1512px (MacBook 14”)
  • Точка переключения layout’а: 1024px (ниже — mobile-вёрстка, выше — desktop)

В коде утилиты выглядят так:

<h1 className="s-text-130/56 s-leading-130/58 s-tracking-[-0.02/-0.02]">
  Repro
</h1>

где s-text-130/56 = «на desktop 130px, на mobile 56px», между — плавно.

Под капотом Tailwind-плагин (уже написан) генерирует CSS:

.s-text-130\/56 {
  font-size: calc(130px * (100cqw / 1512px));
}
@media (max-width: 767.98px) {
  .s-text-130\/56 {
    font-size: calc(56px * (100cqw / 430px));
  }
}

Размер высчитывается как доля ширины окна, пропорции всего сайта (типографика, отступы, grid, rounded, border) сохраняются на любой ширине.

Что даёт

Экономия трудозатрат

  • Вместо 10 макетов — 2.
  • Не нужно повторять стили для 712, 744, 1024, 1280, 1512, 1728, 2560 по отдельности.
  • Визуальные пропорции автоматически те же, что в Figma.
  • Экономия ~30–40% времени на вёрстке.

Визуальное качество

  • На 4K / 2560px сайт не «расклеивается» узким layout’ом посередине, а выглядит «как в макете, только крупнее».
  • На нетипичных устройствах (iPad mini, Galaxy Fold, ultra-wide мониторы) — тоже ок, нет «щелей» между брейкпоинтами.
  • Типографика остаётся типографикой, пропорции букв к ширине колонки — константны. Критично для foundry-сайта.

Риски и когда scale-подход не работает

СлучайРешение
На 4K текст выглядит слишком большимДобавить clamp-обёртку на 1920px — сайт перестаёт расти дальше. +0.5 дня.
Разный layout для планшета и десктопаОдин дополнительный брейкпоинт на 768 или 1024, два набора компонентов. +2–3 дня.
Нужно ровно 1px border всегдаborder-width исключается из scale, остаётся константой.
Дизайнер хочет сильно различающийся mobile и desktopРаботает как есть — два макета покрывают это, scale между ними не размазывает.

Что технически происходит

Плагин tailwind-scale добавляет набор utility-классов с префиксом s-: s-text, s-leading, s-tracking, s-p*, s-m*, s-gap*, s-w, s-h, s-rounded, s-border.

Используются container query units (100cqw) — масштаб считается от реальной ширины контента без scrollbar’а, нет визуального дребезга.

Поддержка — Chrome 105+, Safari 16+, Firefox 110+ (~95% трафика). Для старых браузеров — fallback на vw (работает почти так же, минимальные расхождения на 1–2px).

Что нужно со стороны дизайна

  1. Выбрать канон из двух брейкпоинтов из всех нарисованных:
    • Для mobile — 375 / 390 / 430 (предложение — 430, ближе к современным айфонам Pro).
    • Для desktop — 1280 / 1512 / 1728 (предложение — 1512, средний).
  2. На этих двух рамках финализировать layout. Остальные макеты — референсы, по ним сверяется поведение в промежуточных состояниях.

Альтернатива — классический breakpoint-подход

Если scale-вариант не подходит:

  • Верстаются 3 брейкпоинта: mobile (до 768), tablet (768–1024), desktop (1024+).
  • На каждом — своя точная сетка и размеры.
  • Между брейкпоинтами — «плавающая» адаптация внутри одного layout’а.
  • Дороже на 5–8 инж. дней, но ближе к тому, как чаще всего верстают сайты.

Рекомендация — scale-подход. Для foundry-сайта, где герой — типографика, fluid даёт лучшее качество при меньшей стоимости.