Данная статья поможет улучшить взаимодействие между дизайнерами и верстальщиками для минимизации ошибок и повышения продуктивности работы. Не стоит воспринимать статью за единственно верный подход. Работа богата практическими примерами. Она будет полезна специалистам разного профиля. Дизайн является основой качественной верстки и помогает успешно продолжить создание веб-приложения. Стандартизированные свойства элементов дизайна (цвета, шрифты, размеры, отступы и т.д.) Принцип переиспользуемости. Изменение одних элементов должно приводить к преобразованиям этих элементов в других частях макета. Нужно избегать копирования элементов.- переиспользуйте их. Речь идёт об использовании стилей и компонентов в figma: шрифтов, цветов, отступов и прочего. Порядок в слоях и понятный нейминг - прежде всего это ваш профессионализм. Необходимо подходить к процессу ответственно. Прорабатывать функционирование проекта на мобильных и touch устройствах. Помните об отсутствии hover event  на данных девайсах, не забывайте использовать это в своих макетах. (на десктопе при наведении появляется дополнительный текст, а на мобильных устройствах подобный кейс не учтен.) Для упрощения работы верстальщика дизайнеру стоит делать видео созданных анимаций. Pixel perfect - решение устаревшее. Оно преобладало для растровых макетов, в которых не было возможности уточнить размеры элементов. На этом этапе использовались расширения в браузере для наложения изображений дизайна. Подобный подход использовать не нужно. Не стоит использовать глобальные селекторы по тегам для элементов a, li, ui, h, p и тд, Создавайте классы для более точного выбора. Например, можно завязаться на класс обертку в body .main h1 {}. Глобально h1 - плохо .h1 - хорошо. Помним про принцип переиспользуемости! Старайтесь не задавать высоту элементам (input button и тд) с помощью padding если они имеют статичную высоту в дизайне. Дизайнер задает конкретные параметры элемента в пикселях, поэтому изменение количества строк или внутреннего контента  повлияет на исходные размеры. Поэтому height у элементов задаем в пикселях. Если такое решение необходимо, например кнопка может быть c переносом шрифта в 2 строки, будьте осторожны с внутренним контентом. Возможно следует создать дополнительный класс. Используйте типы размеров правильно. Для элементов в верстке, лучше использовать пиксели, а не другие единицы измерения. Дизайн изначально создан в пикселях, поэтому не стоит вмешиваться в исходные параметры. Проценты тоже необходимо применять аккуратно,  если вы используете что-то помимо 25% 50% 100% то, вероятно, вы делаете что-то не так. 50% если делим поровну 2 блока внутри 1 родителя ну и 25% соответственно 4 блока. Для шрифтов и типографии,  стоит использовать относительные величины rem, em, %. Установка размера шрифта в px предотвращает настройку размера шрифта в настройках браузера, которую определенно используют некоторые люди. В прожектах у которых все элементы кастомные с возможностью принимать любую логику и формы, используя bootstrap и прочие ui системы, вы скорее всего будете обвязывать их дополнительными обертками и костылями, при этом неся за собой неиспользуемый функционал в виде js и style кода. Поэтому в проектах с индивидуальным визуалом рекомендую этого избегать и кастомизировать все под свои нужды. Часто в  том же bootstrap бывает много того, что нам не нужно использовать и мы часть вырезаем а другую кастомизируем. Еще проблемы могут быть при изменении ui библиотек используемых в фраемворках. Если bootstrap или любые длугие ui системы легко применять под ваши договоренности и не требуется сложная кастомизация, вы можете использовать его без каких либо проблем. Ссылка на пример https://github.com/jtapes/styles-example В качестве примера будет использован подход атомарных классов. При этом немного может увеличивается объем html кода. Однако данный подход решается точным и лаконичным написанием небольшого количества классов. Преимуществом данного метода в переиспользование сss стилей, а также минимизация создания классовых оберток. Создавайте и переиспользуйте стили для цветов, не нужно красить пипеткой, наследуя цвет, или копировать hex коды. Малое количество оттенков одного цвета в проекте поможет избежать ненужной путаницы. Не создавайте "50 оттенков серого". Для проекта оптимально около 6 основных и 4 вариаций серого. Вынесение цветовых стилей в ui kit (dashboard) нужно для получения информации о кодах цвета и передачи без использования Figma. Например, можно отправить распечатку заказчику для brandbook. Названия стилей в figma должны совпадать с названиями переменных цветов в коде. Это поможет разработчику ориентироваться и не открывать каждый раз figma для просмотра цвета. Примеры названий main, primary, success, danger, warning Создадим классы цветов и заливки для использования в html. Подключим для `background-color` используем bg-{{name}} .bg-primary .bg-danger для `color` используем color-{{name}} .color-primary .color-danger Кратностью отступов и размеров это соблюдение дизайнером принципа деления всех таких измерений на одно целое число. Стандартом является 4px - значит, все отступы и размеры должны быть результатом произведения 4, на какое-либо целое число.  4px, 8px, 12px, 16px, 20px и тд.  Разрешается использовать 1px и 2px. При необходимости кратность можно поменять (например, 22px или 11px), но лучше соблюдать ее хотя бы к 2px. если базовая 4px. В ином случае нам придется делить пиксель при центровке элементов. Например, у кнопки размер шрифта 11px, а высота кнопки 40px. Делаем наш шрифт по центру кнопки. 40 - 11 = 29/2 = 14.5 (отступ сверху и низу) Браузер сможет справиться  с делением на пиксели - это не проблема. Здесь стоит вопрос эстетичности и легкости процесса верстки страницы. А при разбиении макета по пиксельной сетке в figma не придется выходить за его границы. Не забываем выносить информацию по отступам в ui kit, тут должны быть все договоренности по дизайну. Создаем лист, необходимый для генерации классов: Используем в миксине и создаём классы: Не советую создавать классы для отрицательных отступов и делать более 20 вариаций, так как мы создадим массу редко используемых классов и сильно увеличим css файл для первичной отрисовки. В примере при создании 1 размера создаются 14 классов (из миксина padding и margin) * 4 (все разрешения) - получается 56 классов, поэтому стоит сокращать количество размеров в листе. Создание переменных: До первого size-52 наследуем размеры от $sizes. Для остальных достаточно создать размеры, кратные нашим согласованиям. Внутри команды необходимо запретить разработчикам использовать размеры, нужно обязательно использовать переменные по типу $size-4 $size-32 и тд, а процентные значения допускаются только в формате 100 50 25 процентов, Если все же придется отступить от такого порядка - оставляйте комментарий. Это позволит избежать недопонимания и пояснит, что это - часть дизайна. для `margin` использовать m`{-media}?`-`{size}` (x,y) - оси .m-1 .ml-2 mt-md-1 .mx-4 .my-2 для `padding` использовать p`{-media}?`-`{size}` (x,y) - оси .p-1 .pl-2 pt-md-1 .px-4 .py-2 для иконок можно создать классы - `icon-{size}` Чаще всего необходимы только 3 класса: icon-16 icon-24 icon-32 Как и в случае с цветами и отступами все шрифты необходимо занести в стили figma и вынести в up kit, не создавая при этом десятки вариаций толщины и размера, межбуквенных и межстрочных интервалов. Обычно достаточно следующего: размеры - h1, h2, h3, h4: default text, small text. Начертания - regular, medium, bold. Верстальщику необходимо правильно подключить наши шрифты, нужно конкретно указать браузеру, откуда загружать шрифты regular, bold и т.д., В противном случае браузер сделает начертание bold самостоятельно. Это не будет соответствовать макету. Используйте классы для задания шрифтов у элементов по типу .h1 .h2 или в крайнем случае @mixin h1. Миксины плохи тем что,  дублируют, а не переиспользуют свойства. В верстке нужный шрифт выбираем с  помощью font-weight. Подключение Таблица размеров и типов: Не используйте свойства шрифтов. Если вдруг по какой-либо причине это необходимо, комментарий обязателен. Использование миксинов для базовых классов Зашивать margin bottom в заголовки допустимо, обычно эти отступы для каждого размера шрифта стандартизированы дизайном. Убрать отступы можно следующим образом: - .h1 .mb-0 Все повторяющиеся стили у элементов (тени, радиусы, бордеры) дизайнер также выносит в ui kit. Не рекомендуется делать много вариаций. В верстке выглядит это примерно так: Дизайнер указывает информацию в ui kit: какие точки перестроения интерфейса у нашего приложения. Обычно размеры соответствуют размерам экранов на разных устройствах. Создаём переменные: Создаем миксин для удобства использования медиа условий: Это описание колонок, по которым будут располагаться будущие блоки. Под разные размеры устройств сетка практически всегда будет отличаться, как и межколоночный интервал. Описываем правила в стилях: Для всех кастомных классов используем префикс: Это и есть верстка классовым подходом. Например, очень часто нам нужно выровнять блоки по горизонтали: в данном случае будет достаточно d-f, и не придётся каждый раз создавать классы-обертки. Для `display-flex: flex`используем `d-f` Для `align-items: center`- `ai-c` Список можно постоянно пополнять по мере необходимости Если свойство состоит из 2 слов, используем буквы слов `text-align` = `ta` Если свойство состоит из 1 буквы и не конфликтует с другими -  `display` = `d` При конфликте первой и последней буквы - `border` = `br` или часть слова по логике `background` = `bg` Старайтесь максимально использовать классовую верстку без переменных и миксинов scss. `class="d-f m-4 m-md-4"` - допустимо `class="d-f m-4 m-md-4 d-f m-4 m-md-4 d-f m-4 m-md-4 d-f m-4 m-md-4"` - Плохо. В таких случаях создается класс с описанием свойств внутри него. `class="d-f custom-class"` - не запрещено, но иногда удобней и предпочтительней написать свойство в классе: `display: flex`. Возьмите за правило не писать больше 5 классов в блоке. Не забывайте про классы w-100 h-100, w-50 h-50, w-25 h-25 Подключение `@include z-index(наименование ключа)` Значения z-index заданы с шагом 10 для того, чтобы оставить место для ошибок и настроек. При добавлении нового ключа необходимо предусмотреть все конфликты с существующей картой z-index: Необходимо основательно подходить к процессу верстки и дизайна макета. Это поможет избежать трудностей в реализации проекта и обеспечит легкое, незатейливое сотрудничество между специалистами различных сфер. Front-end developer