Верстка pixel perfect: де макет і продукт розходяться
Верстка pixel perfect не зводиться до збігу двох картинок: макет у редакторі статичний, а інтерфейс — жива конструкція, яка змінюється від даних і дій користувача. Тому розбіжності макета й верстки рідко виглядають як «зсунулося на пару пікселів» — спочатку розходяться принципи.
На сусідніх екранах різні відступи між блоками, на одній сторінці крок сітки кратний, на іншій — випадковий, а вертикальний ритм ламається, щойно в картці з'являється довгий заголовок.
Окрема категорія — стани, яких у макеті просто немає: наведення, фокус, введення з помилкою, порожній список, очікування завантаження.
Зверстані «за картинкою», вони живуть кожен за своїми правилами: кнопка при наведенні змінює не лише фон, а й висоту, а підпис поля з'їжджає при появі повідомлення про помилку.
Точність верстки тут перевіряється не порівнянням кольору, а єдиними токенами розмірів і відступів для всіх станів.
Адаптив під мобільні — головне джерело розбіжностей. У макеті узгоджені крайні ширини, а проміжні — планшет у портретній орієнтації, вузький ноутбук — зазвичай ніхто не малював.
Тому точність верстки перевіряють на неперервному діапазоні ширин: сітка має перебудовуватися за правилами, а не «докотився» до найближчої контрольної точки.
Приймання верстки — це накладання макета на готовий екран за кількох роздільностей, звірка відступів за значеннями, а не на око, прогін усіх станів і крайових даних: найдовше ім'я, порожній блок, список із сотні елементів. Розбираємо, як це закривається на рівні процесу і що потрапляє до критеріїв приймання.
Що дає відповідність макету: ефект у вимірюваних величинах
Точність верстки вимірюється не тим, як сторінка виглядає на погодженні, а тим, як вона поводиться далі — на кожній наступній правці. Коли розмітка зібрана за сіткою з макета, з єдиною шкалою відступів і типографіки, доопрацювання зачіпає лише свій блок.
Там, де цієї дисципліни немає, будь-яка зміна тягне ланцюжок: кнопка поїхала, на вузькому екрані текст обрізався, модальне вікно перекрило підвал.
Швидкість виведення правок
Розмітка на компонентах і токенах дозволяє змінювати елемент в одному місці, а не шукати його по десятках шаблонів.
Правка приходить текстом від замовника і виходить у реліз у тому ж циклі погодження — без раунду «дизайнер намалював заново, верстальник заново розібрав, тестувальник знайшов розбіжності».
На прийманні порівнюють не «подобається чи ні», а накладання на макет, тому спірні пункти закриваються за один прохід.
Частка візуальних відмов
Верстка pixel perfect дає перевірюваний критерій: розбіжності за сіткою, відступами й перенесеннями рядків ловляться автоматично до викладки.
Це скорочує потік задач на кшталт «поправте відступ на мобільному» вже після запуску і звільняє час команди під функціональність, а не під косметику.
Вартість пізніх доопрацювань
Що пізніше знаходиться візуальний дефект, то ширше коло переробки: правка в готовому продукті зачіпає погодження, тести й повторне приймання.
Макет у Figma зі специфікаціями станів і контрольних ширин знімає більшу частину цих ітерацій — інженер бачить цільову поведінку інтерфейсу до початку роботи, а не відновлює її за здогадами.
Підходи до точної верстки: порівняння режимів роботи
Режим роботи з макетом обирають не за смаком дизайнера, а за структурою проєкту: скільки унікальних екранів, як часто вони змінюються і чи є на боці дизайну бібліотека компонентів.
Нижче — варіанти, між якими ми реально обираємо на старті, з їхніми сильними сторонами і ціною підтримки.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Єдина дизайн-система | Багатоекранний продукт із повторюваними блоками й частими релізами | Потрібна дисципліна: відхилення від бібліотеки ламає перевикористання стилів |
| Компонентний підхід | Інтерфейс складається з блоків зі станами й варіантами | Повільний старт, поки не набрано критичну масу компонентів |
| Вільний макет | Односторінковий сайт або промо-сторінка з унікальною графікою | Кожен блок верстається окремо, правки дорожчі, повтори збираються заново |
| Гібридний підхід | Основні сценарії типові, окремі секції авторські | Потрібна явна межа між системою і вільною зоною, інакше стилі розходяться |
Поверх будь-якого режиму ми запитуємо адаптивні версії макета — стани для вузького, середнього і широкого екрана, а не одну картинку під настільний перегляд. Якщо їх немає, контрольні точки погоджуємо окремо і фіксуємо в специфікації.
Саме це робить верстку pixel perfect перевірюваною: відхилення видно за кожної роздільності та на кожному стані компонента, а не лише на макеті дизайнера.
Етапи впровадження: від розбору макета до приймання
Робота починається не з розмітки, а з аудиту макета. Дивимося, чи описані стани екранів цілком: наведення, завантаження, порожня видача, помилка запиту, поведінка довгих заголовків і таблиць.
Якщо цих станів у файлі немає, питання до дизайну закриваємо до старту — правка на етапі розбору дешевша, ніж перебирання готової сторінки.
Як іде робота
- Аудит макета й постановка критеріїв: фіксуємо сітку, контрольні ширини, типографіку та допустиме відхилення за метриками.
- Складання структури: повторювані блоки виносимо в компоненти, щоб один елемент не збирався заново на кожному екрані.
- Верстка сіток і типографіки, включно з проміжними ширинами, про які макет мовчить.
- Перевірка розбіжностей накладанням: звіряємо відступи, розміри, міжрядкові інтервали та позиції іконок з оригіналом.
- Перевірка розбіжностей у живих браузерах: там, де відмінності дають відмальовування шрифтів і системний масштаб інтерфейсу.
- Приймання за чек-лістом станів і роздільностей, з еталонними знімками екранів.
- Передача в підтримку: розбір компонентів, правила стилів і порядок оновлення еталонів.
Така послідовність тримає верстку pixel perfect не лише в день здачі. Еталонні знімки й описані стани перетворюють перевірку розбіжностей на регулярну процедуру — наступна правка макета не обертається перебиранням усієї сторінки.
Склад постачання: регламенти, схеми й еталони сторінок
Верстка pixel perfect — це не лише збіг із макетом на момент здачі, а й комплект матеріалів, за яким результат можна перевірити й далі підтримувати.
Тому разом із кодом замовник отримує набір еталонних станів, правила іменування елементів і регламент приймання — те, що дозволяє приймати роботу без смакових обговорень і вносити правки, не ламаючи сусідні блоки.
- Карта еталонних станів. Для кожної сторінки — базовий, планшетний і мобільний вигляд, а також поведінка при наведенні, фокусі, порожньому списку, довгому тексті й помилці форми. Знімки зроблено на погоджених ширинах, і вони слугують точкою звірки.
- Правила іменування елементів. Єдиний словник для дизайну й коду: блок, елемент, модифікатор. Однакові сутності в макетах і в розмітці називаються однаково — новий розробник знаходить потрібний блок за хвилини, а не за день.
- Опис сіток і відступів. Крок сітки, набір значень відступів, поведінка контейнерів на проміжних ширинах і правила перенесення блоків. Усе зафіксовано числами з дизайн-системи, а не «на око».
- Регламент приймання. Контрольний список звірки з макетом, допустимі розбіжності, перелік ширин екрана й браузерів, перевірка на реальних пристроях. Підсумок — однозначне «прийнято» або список конкретних зауважень.
- Регламент супроводу. Що вважається джерелом істини при розбіжностях, у якому порядку оновлюються еталони, як погоджуються правки і хто відповідає за них на період гарантії.
- Схема повторно використовуваних компонентів. Складені блоки, їхні стани й залежності: новий розділ збирається з готового, а не верстається заново.
- Доступи й передача. Репозиторій, інструкція з локального запуску й збирання, порядок оновлення залежностей і контакт відповідального інженера.
- Супровідна документація. Короткий опис структури проєкту й типових задач: де змінювати кольори, шрифти та відступи, щоб не зачепити решту.
Кожен пункт передається разом із кодом: еталони — як знімки й описи, регламенти — як документ, який відкривають під час наступного доопрацювання. Так точність верстки залишається перевірюваною й після зміни виконавця чи команди.
Кейс: як ми прибрали розбіжності макета й продукту
Клієнт — сервіс з особистим кабінетом і публічними сторінками: близько 40 екранів і понад сотня станів у макетах.
Верстка pixel perfect там не приживалася: сітка плила на проміжних ширинах, відступи розходилися на 4–8 точок, стани кнопок і полів відрізнялися від бібліотеки компонентів. Приймання перетворювалося на список зауважень, який відкривали заново після кожної правки.
Що змінили
Ми зафіксували макет як контракт, а не як картинку. Усі стани компонентів звели в Figma — окремі варіанти для наведення, натискання, очікування, помилки й порожнього поля.
Сітку, відступи й типографіку винесли в токени, щоб значення бралися з одного джерела, а не підбиралися вручну в кожному блоці.
Далі додали автоматичну звірку: зібрана сторінка порівнюється з макетом на кількох ширинах, розбіжності віддаються звітом із координатами.
Що стало за цифрами: частка екранів, прийнятих з першого проходу, зросла з 35% до 92%; кількість ітерацій правок після приймання впала з трьох до однієї; розбіжності на проміжних ширинах — нуль.
Так приймання перестало бути переговорами про смак: спірні місця розбираються за звітом звірки, а не за скриншотами з чужого монітора. Правки після здачі залишилися, але їх стало на порядок менше — і вони стосуються поведінки, а не геометрії.
Чим сітка відрізняється від попіксельного порівняння макетів?
Контроль за сіткою — звірка з правилами макета: кількість колонок, проміжки між ними, крок відступів, базові лінії тексту, поведінка на контрольних ширинах. Інженер накладає сітку на живу сторінку і бачить, що блоки займають передбачувані треки, а відступи кратні кроку.
Так зникають системні розбіжності: різна ширина однотипних карток, «поїхала» розкладка, роз'їжджаються заголовки.
Попіксельне порівняння йде від зображення: макет суміщають із живим екраном при масштабі 100% і читають різницю через віднімання або напівпрозоре накладання.
На повторюваних перевірках це автоматичне порівняння знімків із порогом відхилення — видно зсуви на один-два пікселі, чужа товщина шрифту, неправильний міжрядковий інтервал.
Способи відповідають на різні питання: сітка пояснює, чому елемент стоїть не там, пікселі — що саме змістилося. Обмежитися накладанням не можна: анімація, стани наведення й відмінності середовищ дають хибні розбіжності, і перевірка тоне в шумі.
| Критерій | Контроль за сіткою | Попіксельне порівняння |
|---|---|---|
| Що перевіряє | колонки, поля, крок відступів, базові лінії | зсуви елементів, кегль, міжрядковий інтервал |
| Коли застосовуємо | з першої верстки, на кожній контрольній ширині | після складання блоку й перед здачею сторінки |
| Сліпа зона | локальні зсуви всередині блоку | хибні розбіжності на анімації та станах |
Тому порівняння способів контролю вибудовуємо у два проходи: спочатку сітка на всіх контрольних ширинах — вона знімає основну частину розбіжностей, потім накладання на макет, де шум від згладжування відсікаємо порогом.
Саме так збирається верстка pixel perfect — за двома незалежними перевірками, а не за однією. До звіту перевірки розбіжностей потрапляють лише підтверджені відмінності з координатами й причиною.
Часті сумніви щодо термінів і якості: докладний розбір
Макет описує один стан сторінки, а в живому застосунку їх десятки: довгий заголовок, порожня картка, текст у два рядки замість одного.
Тому піксель-перфект перевіряємо не на ідеальних даних, а на граничних — підставляємо найдовший і найкоротший вміст і дивимося, де блок розтягується, а де ламається. Окремо проганяємо стани завантаження й помилок: саме там найчастіше розходяться відступи й висоти.
Адаптивні версії верстаємо за контрольними ширинами з Figma, проміжні перевіряємо на переповнення — таблиці, довгі слова, вкладені списки. Розбіжність фіксуємо у звіті скриншотами накладання: видно, який елемент і на скільки відхилився від макета.
Після здачі точність не розпливається. Правки вносяться у вихідники й проходять ту саму перевірку накладанням, що й первинна верстка, тому новий блок не зводить сусідні.
Відповідальність розмежовуємо одразу: відхилення від нашого коду — правимо самі, розбіжність через правку контенту чи стороннього модуля — показуємо причину й пропонуємо варіант.
А якщо макет оновлять після здачі — верстка поїде?
Ні, якщо зміни йдуть через вихідники. Накладаємо новий макет на поточну сторінку і бачимо, які блоки зачеплені, а які залишилися на місці. Якщо правиться спільний контейнер або сітка — перевіряємо всі залежні секції, а не лише змінену.
Обговоримо задачу: що потрібно для старту робіт
Щоб стартувати без пауз і не переробляти готові блоки, нам потрібен один набір вихідних даних. Зазвичай саме їхня відсутність розтягує роботу: макет є, а поведінка елементів при наведенні й на різних екранах не описана, і верстальник вгадує. Збираємо все один раз — далі рухаємося без повернень до листування.
- посилання на макет із доступом на перегляд: десктопна й мобільна версії, стани кнопок, полів, спадних списків і спливних вікон;
- пріоритетні ширини екранів, на яких верстка pixel perfect найважливіша, і поведінка між ними;
- список браузерів і пристроїв, де інтерфейс зобов'язаний виглядати однаково;
- тексти, зображення та іконки у вихідній якості або позначка, що наповнення беремо на себе;
- перелік форм і зовнішніх сервісів: куди йдуть заявки, які поля обов'язкові, яка перевірка введення потрібна;
- вимоги до розмітки й доступності, якщо вони зафіксовані на вашому боці;
- контакт людини, яка ухвалює рішення щодо спірних місць дизайну.
Порядок обговорення простий: зідзвонюємося на 30–40 хвилин, проходимо макетом екран за екраном, відзначаємо непокриті стани й одразу домовляємося, хто їх закриває.
Після розбору повертаємося з оцінкою та планом робіт — розбивка за етапами, терміни, склад перевірок і список ризиків із рішеннями. Опишіть задачу й додайте вихідні дані — повернемося з оцінкою та планом під ваш проєкт.
