🖥 Почему для PC‑макета мы просим 1600?

Нас часто спрашивают дизайнеры: почему лучше рисовать десктоп именно на 1600, а не на 1440, 1366 или 1920?

Короткий ответ: для флюидной вёрстки это самая удобная точка отсчёта.

Мы собираем сайты во флюидной логике. Элементы не зафиксированы в пикселях, а пропорционально меняются вместе с шириной окна браузера. И от того, какое разрешение макета мы возьмём за основу, зависит, насколько сильно эти элементы будут масштабироваться у пользователя.

Обычно нам хватает трёх точек:
📌 1600 для PC
📌 768 для планшета
📌 390 для мобильной версии

Почему именно 1600?
Потому что это золотая середина, которая даёт адекватные пропорции при растягивании и сжатии экрана.

Смотрите, как это работает на практике:
• Если взять за базу 1280, то при просмотре на мониторе 1920 все элементы увеличатся в полтора раза — интерфейс станет гигантским. Придётся добавлять новые брейкпоинты, чтобы это успокоить.
• Если верстать от 1920, то на экранах компактных ноутбуков (1366px) всё сожмётся почти на треть и станет слишком мелким.

При базе 1600 мы получаем комфортный баланс. На широких мониторах контент не раздувается до неадекватных размеров, а на небольших ноутбуках остаётся читаемым и аккуратным.

Конечно, дизайнеры часто отдают макеты в 1366 и 1920. С этим тоже можно работать: верстать от 1366 и корректировать отступы на 1920. Но если на 1920 реально меняется сетка и композиция — это уже отдельная полноценная вёрстка.

Для большинства лендингов 1600 закрывает десктоп без лишних костылей и новых состояний.

А в следующем посте мы отойдём от пикселей и разберём, почему такую вёрстку гораздо удобнее и быстрее собирать в rem. 🧮

Зачем мы верстаем в rem? 🧑‍💻

В Taptop можно работать с разными единицами измерения: px, vw, vh, em и rem. У каждой из них своя логика, но для флюида подходит не всё.

Пиксели понятные, но жёсткие. Если задать элементу 40px, он так и останется 40px, независимо от ширины экрана. А нам нужно, чтобы размеры интерфейса пропорционально менялись.

С vw элементы начинают зависеть от ширины окна. Но собирать весь проект только в vw — это боль. При переходе на каждый новый брейкпоинт (на планшет или мобилку) вам придётся заново пересчитывать в калькуляторе вообще все значения из макета.

em тоже может запутать. Эта единица привязана к размеру шрифта конкретного блока. Из-за этого отступ 3em у крупного заголовка и у мелкого абзаца даст на экране абсолютно разные расстояния.

А вот rem работает спокойнее. Он привязан к одному единственному корневому элементу (root), поэтому 3rem всегда дают предсказуемый размер для любых блоков.

Но просто переключиться на rem недостаточно. Традиционно за основу корня берут 16px. Под эту базу созданы десятки сервисов-конвертеров. Но пересчёт от 16 сложный: чтобы получить точные отступы из макета, нужно постоянно держать калькулятор открытым.

Мы делаем иначе: через embed с глобальными стилями прописываем скрипт и задаём корень так, чтобы на основном разрешении макета он был равен ровно 10px.

Например, если макет нарисован на 1600, значение в скрипте получается 0.625vw. Для макета на 1440 цифра будет другой, но суть остаётся.

Как только root настроен на 10px, мы полностью освобождаемся от калькуляторов. Начинается нормальная жизнь:
• в макете отступ 40px → просто пишем 4rem
• заголовок 56px → ставим 5.6rem
• элемент 120px → пишем 12rem

Берём значение из Figma, мысленно делим на 10 и переносим в Taptop. А когда доходим до адаптива, логика сохраняется. Вам не нужно пересчитывать значения элементов руками — вы просто добавляете в скрипт нужный брейкпоинт (планшет или мобилку) и его vw‑значение.

Ещё один нюанс. В скрипте можно оставить PC без ограничений — тогда интерфейс будет флюидно расти вместе с шириной монитора. А можно поставить потолок (например, на 1920): после этой точки элементы зафиксируются в абсолютных значениях. Это отлично выручает, когда на огромных экранах всё начинает казаться слишком гигантским. 🖥

🔎 Почему не стоит сразу прыгать в вёрстку?

Очень хочется открыть конструктор и сразу начать собирать первый экран. Макет вроде понятный, лендинг небольшой, кажется, можно просто «начать и разобраться по ходу».

Но перед стартом лучше внимательно изучить макет.

Не пробежать глазами за пару минут, а реально посмотреть структуру, разрешения, состояния и спорные места. Да, на это нужно потратить время. Но часто именно это время потом экономится в процессе вёрстки.

Важно заранее понять:

• какие есть разрешения
• сколько блоков в проекте
• есть ли UI-kit
• прописаны ли состояния: hover, active, disabled, error
• всё ли понятно по адаптивам
• всё ли дизайнер подготовил корректно
• какие вопросы лучше задать до старта

Последний пункт особенно важен. Вопросы к макету и ошибки лучше поймать до вёрстки, а не когда уже готова половина сайта.

Типичный пример — текстовые стили.

Один и тот же текстовый элемент должен оставаться одной сущностью на всех разрешениях. Если на десктопе это H3, он не должен на планшете внезапно превращаться в H6 или любой другой стиль из типографики.

Размер, межстрочка, ширина и поведение на адаптиве могут меняться. Но логика элемента должна сохраняться.

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

Если сразу прыгнуть в вёрстку «с первого экрана», очень быстро можно упереться в вещи, которые проще было спросить у дизайнера заранее.

Например, когда неясно, как должна работать задуманная анимация или какая логика заложена в интерактивный блок. Угадывать поведение или переделывать готовое гораздо дольше, чем уточнить детали на старте.

В моменте кажется: «Разберусь по ходу».

Но часто это превращается в переделки.

Когда мы заранее изучаем макет, становится понятнее, что вынести в базу, какие элементы собрать в UI-kit, где могут понадобиться дополнительные настройки и какие вопросы лучше задать до начала сборки.

Поэтому нормальный старт вёрстки начинается не с первого div’а.

Сначала смотрим макет.
Понимаем структуру.
Проверяем текстовые стили и состояния.
Собираем вопросы к дизайнеру.

И только потом идём верстать.

Так меньше сюрпризов, меньше переделок и меньше ситуаций из серии «а почему это всплыло только сейчас?» 😎

Салют, друзья! 🤘

Открываем четвёртый урок бесплатного курса по Taptop.

На этот раз верстаем обложку лендинга. Урок разбили на 3 части, чтобы спокойно пройтись по структуре, деталям и адаптивам.

Внутри сначала разбираем важный момент с SEO: семантические теги для Header, Nav, Main, Section и заголовков.

Потом собираем саму обложку: секцию Cover, контейнер, cover-wrap, высоту на весь экран, внутренние отступы и границы.

Отдельно подробно разбираем Auto Layout: Grid: как он работает, как настраивать, как выставлять элементы и чем отличается от Flex.

Дальше добавляем внутренние элементы: буквы ГКВ через div-маски, центральный блок с заголовком, текстом и кнопкой, отдельный H1 для SEO, серый фон, линии и декоративные квадратики.

В финале адаптируем обложку под планшет и мобильную версию: меняем колонки, отступы, размеры букв, расположение центрального блока и настраиваем 100svh, чтобы обложка корректнее работала на мобильных устройствах.

Новый урок уже доступен в боте: @Izum_Study_bot

Смотрите, пробуйте повторить за Андреем и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

Салют, друзья! 🤘

Открываем пятый урок бесплатного курса по Taptop.

На этот раз собираем блок «Красные флаги». Это не обычный слайдер с кнопками или свайпом, а блок, который работает по скроллу.

Урок разбили на 2 части.

Сначала собираем статику: структуру блока, линии, декоративные квадратики, контентную часть, карточки и визуалы.

Потом переходим к самому интересному: настраиваем и разбираем позиционирование sticky, отключаем pointer-events там, где это нужно, и собираем анимацию смены слайдов по скроллу.

В итоге получается блок, который фиксируется на экране, а карточки, номера, заголовки и описания меняются во время движения страницы.

Новый урок уже доступен в боте: @Izum_Study_bot

Смотрите, пробуйте повторить за Андреем и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

👀 Perfect pixel или флюид?

Perfect pixel звучит красиво. Взяли макет, перенесли всё пиксель в пиксель. Получили идеальное совпадение.

Но есть нюанс. Сайт живёт не в одном размере экрана. У пользователей мониторы на 1280, 1366, 1440, 1600, 1920. Плюс куча промежуточных вариантов, планшеты, мобилки, разные браузеры и высоты окон.

Если держать всё строго в пикселях, быстро вылезает проблема. На одном разрешении всё ровно, а на другом уже нужно отдельно править.

И чем жёстче подход, тем больше состояний придётся собирать.
Сначала делаем идеально на 1280.
Потом отдельно на 1366.
Потом на 1440, 1600 и 1920.
Плюс планшет и мобильные версии.

Так для одного лендинга набирается 10–12 состояний. И всё это только ради того, чтобы выглядело «как в макете».

Флюидная вёрстка решает задачу иначе.

Мы не прибиваем элементы к жёстким размерам. Мы задаём логику, по которой всё пропорционально меняется вместе с шириной экрана.

Это не значит, что можно забыть про аккуратность. Наоборот. Флюид требует чёткого понимания: от какого разрешения строим базу, как всё масштабируется, где реально нужен breakpoint, а где он будет лишним.

Зато сайт ведёт себя спокойнее.
Он не скачет от одного жёсткого макета к другому.
Не требует ручных правок на каждом промежуточном размере.
И не превращает адаптив в бесконечный список исключений.

Perfect pixel отлично работает там, где размер всегда фиксированный. Но сайты почти никогда не живут в одном размере.

Поэтому для современных сайтов флюид удобнее. Это меньше ручной подгонки, минимум лишних breakpoint’ов и полный контроль над интерфейсом между экранами 😎

Салют, друзья! 🤘
⠀
Открываем шестой урок бесплатного курса по Taptop.
⠀
На этот раз собираем большой блок «Чеклист». Урок получился объёмный, поэтому разбили его на 5 частей.
⠀
Внутри будет 4 раздела, у каждого свой цвет фона, своя структура контента, а заголовки фиксируются, пока правая часть движется при скролле.
⠀
Первые два раздела собираем в более спокойной логике: заголовок фиксируется, а контент движется при скролле.
⠀
Дальше переходим к большим разделам, где контент выходит за пределы экрана и появляется из-под нижней пунктирной линии. Для этого отдельно собираем закрывающую плашку, настраиваем sticky, z-index, декоративные элементы и аккуратное перекрытие контента.
⠀
Отдельный важный момент урока — Custom Properties. Разбираем, где они помогают и как с ними работать.
⠀
В финале собираем навигационное меню внутри чеклиста: фиксируем его при скролле, добавляем переходы по якорям, активные состояния пунктов и небольшую анимацию со скобками.
⠀
Новый урок уже доступен в боте: @Izum_Study_bot
⠀
Смотрите, пробуйте повторить и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

⚠️ Почему em может быть неудобен в отступах ⚠️

em — рабочая единица измерения. Но в отступах она часто ведёт себя неочевидно.

em всегда зависит от размера шрифта конкретного элемента. Звучит безобидно, пока не начинаешь ставить отступы.

Например, задаём margin 3em.
У текста с font-size 16px получаем одно расстояние.
У заголовка с font-size 56px те же 3em превращаются уже в совсем другой отступ.

Технически всё верно. Но визуально начинается хаос: в настройках одно и то же значение, а на экране — разные расстояния. Чем больше текстовых стилей в проекте, тем сложнее держать систему под контролем. Особенно если хочется, чтобы отступы были предсказуемыми.

💡 В этот момент на сцену выходит rem

rem не завязан на конкретный текст. Он зависит только от корневого элемента. Поэтому 3rem остаются понятным, стабильным значением для разных блоков. Отступ не прыгает только потому, что внутри другой размер шрифта.

Это сильно упрощает жизнь в вёрстке:
– не нужно каждый раз вспоминать, какой сейчас font-size у элемента
– не нужно заворачивать текст в лишние обёртки ради «нормальных» отступов;
– не нужно гадать, почему одинаковое число выглядит по-разному.

По итогу:
em полезен в своих задачах, но для базовых отступов в лендинге он может быть неудобен.
Если нужна предсказуемая система размеров, rem обычно спокойнее. Меньше сюрпризов, меньше ручных правок и меньше ощущения, что отступы живут собственной жизнью 😎

👀 Когда дополнительные breakpoint’ы реально нужны?

Есть ощущение, что чем больше разрешений в макете, тем лучше будет сайт.
1280, 1366, 1440, 1600, 1920, планшет, мобилка, маленькая мобилка — звучит так, будто «мы предусмотрели всё».

На практике это не всегда так.

Дополнительный breakpoint нужен не тогда, когда «давайте ещё одно состояние на всякий случай».
Он нужен, когда на этом разрешении реально меняется поведение интерфейса.

Например:
• перестраивается сетка
• меняется композиция блока
• элементы ведут себя по‑другому
• появляется другая логика меню
• контент нужно распределить иначе
• флюид уже не даёт нормальный результат

Вот тогда отдельное состояние имеет смысл.

Если же структура остаётся той же, элементы нормально тянутся, пропорции не разваливаются — новый breakpoint чаще всего просто добавляет работы. Потому что каждый breakpoint — это не красивый экран в Figma, а ещё одно состояние, которое нужно сверстать, проверить, поддерживать и не сломать при следующих правках.

Другое дело, если, например, на 1920 у вас действительно другая композиция, более широкая сетка или дополнительные блоки. Тогда да, макет под это разрешение нужен. Верстальщик должен точно понимать, как сайт должен вести себя на больших экранах.

По итогу:

breakpoint добавляем не ради красоты в презентации, а под конкретную задачу.
Если интерфейс меняется — отдельное состояние оправдано.
Если всё просто аккуратно масштабируется — не плодим лишние.

Меньше хаоса в макете, меньше костылей в вёрстке 😎

🔥 Начинаем большую перезагрузку IZUM.STUDY 🔥

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

За брендинг отвечал Саша Лагута. Представлять его долго не нужно: сооснователь Dprofile, автор дизайн-клуба «Плюс к уровню» и абсолютный тяжеловес UI/UX (больше 90 наград на Behance и 50+ на Dprofile). Экспертиза железобетонная.

Вместе с Сашей мы ушли в дерзкий гиковский стиль. Пиксель-арт, брутальная сетка, строгая типографика и кислотные акценты на 100% попадают в нужный вайб.

Прямо сейчас на основе этого стиля мы вовсю пилим новый сайт IZUM.STUDY. А пока работа кипит, залетайте на Dprofile — там уже лежит большой кейс, где можно рассмотреть наш обновлённый визуал в макетах и на мерче.

🔗 Оценить проект: https://dprofile.ru/case/183324/izumstudy

Что скажете по стилю? Как вам такой шаг в сторону диджитал-эстетики? Пишите в комменты 👇

Салют, друзья! 🤘
⠀
Открываем седьмой урок бесплатного курса по Taptop.
⠀
На этот раз собираем блок FAQ. Урок получился объёмный, поэтому разбили его на 6 частей.
⠀
Внутри будет две зоны: аккордеон с вопросами и ответами, а ниже карточка UI-kit, которая появляется при скролле.
⠀
Сначала собираем основу раздела: сетку, декоративные линии, боковые колонки с буквами ГКВ и центральную часть под контент.
⠀
Дальше разбираем два подхода к аккордеону: сначала нативный виджет Accordion в Taptop, потом более гибкий вариант через div-структуру и CMS-коллекцию.
⠀
Отдельно настраиваем кастомный скрипт, чтобы аккордеон открывался плавно, стрелки работали аккуратно, а лишние элементы закрывались автоматически.
⠀
Во второй части блока собираем карточку UI-kit: верстаем изображение, текст, кнопку, добавляем маску и небольшой параллакс при скролле.
⠀
В финале адаптируем блок под планшет и мобильную версию, правим z-index, overlay-плашку и добавляем no-break скрипт, чтобы предлоги не висели в конце строки.
⠀
Новый урок уже доступен в боте: @Izum_Study_bot
⠀
Смотрите, пробуйте повторить и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

🧩 Что такое vw и как мы делаем флюид

Для флюидной вёрстки vw это база. Единица жестко привязана к ширине окна браузера. Экран шире, значит блок больше. Экран уже, блок меньше. Дубовые пиксели так не умеют: задали 40px, и они застрянут в одном размере на всех мониторах.

Благодаря vw всё масштабируется плавно, без резких скачков между брейкпоинтами. Это идеально для флюида.

Но верстать всё напрямую в vw это настоящая боль. В Taptop встроенный калькулятор корректно работает только при верстке на разрешении макета. Будете писать всё в vw, жестко привяжетесь к одному разрешению (например, к 1600px). И если вы перейдете на 1440px, но попытаетесь вбить значение из макета на 1600px, калькулятор переведет всё в vw неверно. Так верстать не очень-то и удобно.

Плюс на всех новых брейкпоинтах придется пересчитывать каждое значение в vw. Вероятность ошибиться и что-то упустить просто огромная.

Поэтому на менторстве мы используем другой подход. Берем rem и специальный скрипт, который сам цепляет rem к ширине экрана.

Что это дает:
• сохраняется полная флюидность
• все элементы зависят от ширины окна
• мы работаем с нормальными значениями в rem
• быстро переносим размеры из Фигмы без сломанных расчетов

Вместе они дают идеальный флюид. Сайт тянется, а верстальщик не тратит часы на перепроверку математики 😎