"Разработчик – это человек, который переводит мысли заказчика на язык машины"
@mikita_du
Идея статьи появилась год назад, думал назвать «Вёрстка в 2021», но как-то затянулось…
Весной 2021 года Microsoft объявила, что с 15 июня 2022 года прекращается поддержка IE11 (да, не для всех версий Win 10, но всё же), а значит, к выходу статьи уже останется менее полугода до знаменательного события, когда не придётся верстать под IE.
Для меня же это значит, что можно будет по полной использовать новые стандарты браузеров, в частности – css-variables, grid layout.
1. Введение
С чего начинается вёрстка? Начинается всё с дизайна. А конкретнее вот этих цифр – 16, 32, 24 (магическая последовательность).
Не многие знают, но эти цифры называют ритмом в дизайне. Это кратность. В данном случае - кратность отступов 8-ке. Если взять 8px как основу, то 16, 24 и 32 – это 8*2, 8*3 и 8*4 соответственно.
Обычно дизайнеры делают все отступы на странице кратными какому-то числу. Нам же важно знать только то, что так мы лучше воспринимаем информацию. И что все эти отступы высчитываются от одного числа простым умножением.
Программисты получают дизайны в Figma (как, например, я - скриншоты выше), где, собственно, и могут заметить эти магические числа. Пользуясь нехитрой логикой, ленивые программисты (а я надеюсь читатель ленивый, а-то какой-то неправильный получается программист) запишут эти значения в переменные и будут использовать далее. Например, это можно записать как offset-1 = 8*1, offset-2 = 8*2 и т.д (в стиле material-ui).
Однако не всё так прекрасно в этом дизайне:
Дизайн той же страницы. Везде восьмёрки, а тут, видите ли, девятка.
Ну и что с ней сделать?
Нужно идти к дизайнеру…
Приходим, спрашиваем – «Что тут по отступу? Ты ошибся и тут 8? Как и везде писать?». И я просто уверен, что он, не задумываясь, ответит – «Да, везде же 8».
И правильно, вы ведь пришли к нему, подумав, а он вам верит. Аргументацию вы привели логичную (везде восьмёрки), всё вроде супер, конечно, 8.
Только есть одно «НО»… Дизайнер не пишет (цифрами, текстом) отступы между компонентами, секциями и прочими элементами на странице. Он просто двигает картиночки по сетке (в лучшем случае), а то и просто до автовыравнивания элемента.
В примере выше и вы, и дизайнер смотрели только в определённое место в дизайне – на отступы. А информация о том, какой контекст был у дизайнера в момент рисования макета, потерялась в разговоре.
А контекст следующий. Ширина блока на странице = 343px (как видно на первых скриншотах).
(343 – 9) / 2 = 167 (как вы понимаете – ширина колонки).
Получается, всё там правильно. Просто контекст не тот. Конкретно, этот отступ брался не из понимания ритма страницы, а банально из способности вместить контент в страницу. Чётное число там не может подойти.
Итак, возвращаемся к нашему коду.
Допустим, мы всё-таки выяснили, откуда взялось это число, но как тогда быть с этим счастьем разработчику?
Создавать новую переменную отступа? – Так она не кратна 8-ке.
То есть делать новую группу отступов, кратную 9-ке? – Звучит не очень, громоздко и непонятно.
Опять что ли к дизайнеру идти? – Ну так понятно, что он был прав, вроде уже всё разгадано.
Ай, поставлю как есть... (это прямо не шутка, лень – страшная штука, не недооценивайте её).
И получается такое счастье:
И как это читать? Где тут записана логика всех мыслей, что у нас были в момент написания?
Получается, мы никуда не записываем придуманную дизайнером логику. Мы просто копируем то, что дизайнер наделал в графическом редакторе. Аналогично и наш дизайнер – никуда не пишет логику отступов. Например, что между заголовком и формой отступ 32px, а между элементами формы в 2 раза меньше – 16px. Всё забывается сразу, как придумано.
Это же ужасно! Получается, мы теряем важные части кода – ещё на этапе создания дизайна.
Так я встал перед вопросом – как же исправить вышеизложенное? Как сохранить контекст, а главное – кто должен это делать и где?
2. Идея
Думал очень долго, а потом наткнулся на интересную идею. А что, если ввести специальные переменные, которые будут сохранять логику подсчёта?
Что, если вместо копирования 9px нам нужно было на основании общей ширины контейнера (343px) найти отступ, предполагая, что колонки будут равны (167 из дизайна).
Т.е, по сути, записать уравнение (343 – x) / 2 = 167.
Или x = 343 - 167*2.
В результате мы бы получили, что отступ равен 9px.
Вроде уравнение с числами читаемости не прибавило. А давайте заменим числа в нём на переменные:
$betweenColumnOffset = $screenWidth - $columnWidth * 2О, другое дело. Так понятна зависимость.
И к дизайнеру второй раз ходить не нужно, да и код теперь поддерживаемый. А главное – гибкий. Если мы изменим ширину экрана – нам не нужно будет считать отступ заново.
3. Media queries
Код на рисунке выше выглядит несколько сумбурно. Тут, конечно, есть вопросы с разделением кода, можно вынести в отдельные файлы переменные и т.д., но давайте двинемся дальше. Что, если у нас приложение не только для мобильных телефонов? Допустим, мы делаем версию и под планшеты, и под разные экраны компьютера (от FullHD, до Ultra Wide). Здесь придётся добавлять media queries. И код станет ещё более завален переменными.
Данную проблему мы решим с помощью css-variables:
С учётом того, что колонки у нас занимают всю доступную ширину экрана (100%), можно убрать переопределение --betweenColumnOffset и заменить фрагмент на следующий:
Так мы получаем автоматически генерируемые отступы на основании ширины колонок из дизайна. Логику можно достаточно просто инвертировать, и считать ширину колонок на основании отступа между ними и ширины экрана. Имеется в виду --columnWidth: calc(100% - var(--betweenColumnOffset). Где --betweenColumnOffset переопределяется в media-queries.
Можно применить такой подход на все элементы в проекте.
У вас будут динамичные отступы между заголовками и элементами.
Между элементами формы.
Отступы внутри контейнеров (карточки, либо формы логина).
Всё это может быть динамически генерируемое на основании переменных и вытекать
из логики заказчика, переданной вам в форме дизайна.
А главное – поддержка и написание будет занимать куда меньше времени и всё будет ровным, потому что вы не будете делать pixel perfect, а будете переводить мысли заказчика в код.
Я сделал уже 4-5 проекта применяя данный подход. На одном за две недели даже пришлось применить три разных дизайна. Частично меняя логику переменных, конечно, но всё-таки скорость великолепная. Работает отлично, единственное – это не получается завернуть в библиотеку, потому как если стандартизировать, то получится что-то узко применимое только к определённому дизайну, в стиле bootstrap или material ui.
Поэтому я сделал 3 репозитория, в которых попытался отобразить варианты того, как можно применять css-variables + scss, либо css-variables + styled-components для сохранения логики заказчика и дизайнера.
styled-components + куча компонентов – (собственно, это и есть попытка сделать стандарт, но ничего не выходит из-за того, что основная идея – подстраиваться под заказчика, проект, дизайнера, а не плодить очередную библиотеку)
В следующей статье я буду рассказывать про прекрасный опыт 3-х дизайнов за две недели, чтобы показать ход рассуждений и плюсы/минусы от применения данного подхода.
Все примеры будут на базе репозитория с scss, поэтому советую ознакомиться.
(Часть 2)
