jtape 6 мар 2022 в 10:10

Паттерны верстки. Как объединить верстальщиков и дизайнеров

11 мин

12K

Веб-разработка*CSS*Оболочки*Расширения для браузеровГрафический дизайн*

Комментарии 13

BlackStar1991 6 мар 2022 в 10:57

Дизайн - это творчество, а ты своим СSS пробуешь загнать дизайнеров в рамки, это так не работает... Опытные дизайнеры и так знают, что можно делать, а что - нет. Другой вопрос насколько они ленивы что бы это выполнять.

за бездумное использование !important я бы вводил смертную казнь или принудительное кастрирование... И не только потому, что из-за таких чудо frontend-ов что бы потом сайт на AMP перевести надо его переписывать, но и ещё и-за добавления проблем в приоритетах стилей. Пожалуйста не надо так! Используйте каскадность. Ваша идея реализуема только в приделах какой-то конторки которая клепает сайт (возможно дорвеи) пачками, где всё +- одинаково, что-то по типу онлайн-казино.

jtape 6 мар 2022 в 12:06

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

за бездумное использование !important я бы вводил смертную казнь или принудительное кастрирование

где вы увидели бездумное использование important в моих примерах?

использование important для атомарных классов - это адекватное ращение, так как из за специфичности селекторов без important будет проблемы

даже сам bootstrap 5 и многие другие фреймворки используют important

посмотрите исходный код
https://github.com/twbs/bootstrap/blob/main/dist/css/bootstrap-utilities.css

Ваша идея реализуема только в приделах какой-то конторки которая клепает сайт (возможно дорвеи) пачками

Приведенные мной наработки зарекомендовали себя на достаточно крупном проекте. Если договоренностей не будет, это скорее и будет не поддерживаемый код в "приделах какой-то конторки которая клепает сайт "

SiR2104 7 мар 2022 в 08:36

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

skeevy 6 мар 2022 в 12:34

Не задавать высоту элементам (input button и тд) с помощью padding. Дизайнер задает конкретные параметры элемента в пикселях, поэтому изменение количества строк или внутреннего контента повлияет на исходные размеры. Поэтому height у элементов задаем в пикселях

Дизайнер как раз должен учитывать ситуацию переполнения контента, и не задавать паддинги не вижу смысла по причине ниже

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

Еще как стоит. В бытность мою работы на фрилансе и ~~галере~~ веб-студии мне приходили макеты только для десктопа, при необходимости самому допиливать мобилку. Даже если и есть мобильные макеты, вы все-равно предлагаете отказаться от rem/em/%?

Получается, что:
1) Вместо установки rem на боди и пропорциональному уменьшению/увеличению его на мобилке, я должен буду руками ходить все исправлять?
2) Я не учитываю работу клиентского устройства под разного рода масштабированием

А масштабирование - это элемент доступности, вы предлагаете делать интерфейсы недоступными, просто потому что дизайнер прав? А если он не прав?

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

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

используя bootstrap и прочие ui системы, вы скорее всего будете обвязывать их дополнительными обертками и костылями, при этом неся за собой неиспользуемый функционал в виде js и style кода. Поэтому в проектах с индивидуальным визуалом стоит этого избегать и кастомизировать все под свои нужды.

Почему стоит избегать? Опять же, тот же бутстрап позволяет атомарно пересобрать свою сетку просто импортируя к себе нужные scss файлы и дальше вот те примеры по изобретению велосипеда не нужны от слова совсем.
Например, откопал такие участки кода в своих проектах +-3 лет давности :

@import 'node_modules/bootstrap/scss/bootstrap-reboot.scss';
@import 'node_modules/bootstrap/scss/bootstrap-grid.scss';
@import 'node_modules/bootstrap/scss/utilities/_sizing';

/* Vars:
   ========================================================================== */

// Font
$mainFont: 'HelveticaNeue', 'Helvetica', 'Arial', sans-serif;
$mainFontColor: #101010;

//desktops
$large_desktop: 1440px;
$small_desktop: 1200px;
//tablets
$large_tablet: 992px;
$small_tablet: 768px;
//phones
$large_mobile: 576px;
$small_mobile: 460px;
//core font
$mainFontSize: 16px; //16px
$mainFontWeight: 400;
$mainLineHeight: 150%; //24x or 1.25rem
$boxHeight: $mainLineHeight;

//bootstrap sizing
$grid-gutter-width: 40px;
$grid-columns: 10;

$grid-breakpoints: (
  xs: 0,
  sm: $large_mobile,
  md: $small_tablet,
  lg: $large_tablet,
  xl: $small_desktop,
  xxl: $large_desktop,
);

$container-max-widths: (
  sm: 540px + $grid-gutter-width,
  md: 720px + $grid-gutter-width,
  lg: 960px + $grid-gutter-width,
  xl: 1170px + $grid-gutter-width,
  xxl: 1320px + $grid-gutter-width,
);

$gutter: $grid-gutter-width / 2;

И дальше использовались те же классы или миксины бутстрапа. При этом, 0 js, потому что в моем случае мне только сетка и нужна.

alexanderniki 7 мар 2022 в 01:00

Поясните, пожалуйста, момент про em/rem.

Допустим у нас есть компонент-карточка. А еще у нас есть заранее оговоренная система размеров и отступов для карточки.

Получается, что, если мы зададим размеры карточки и отступы внутри нее в em/rem, то, при изменении базового размера шрифта, "поплывет" вся верстка. Условно говоря, было у нас расстояние между элементами 16px, а стало внезапно 18px. Просто потому что вот так прописали в media queries для этого min-width.

В то же время, насколько я вижу, браузеры весьма неплохо справляются с масштабированием значений в пикселях при изменении размера экрана или плотности пикселей.

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

skeevy 7 мар 2022 в 11:58

"поплывет" вся верстка

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

браузеры весьма неплохо справляются с масштабированием значений в пикселях

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

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

остается только отступы межды элементами и то, в некоторых юзкейсах, например, том же масштабировании, когда перестраивается интерфейс, отступы в пикселях выглядят отвратительно :)

jtape 7 мар 2022 в 05:49

Большое спасибо за комментарий)

Еще как стоит. В бытность мою работы на фрилансе и ~~галере~~ веб-студии мне приходили макеты только для десктопа, при необходимости самому допиливать мобилку. Даже если и есть мобильные макеты, вы все-равно предлагаете отказаться от rem/em/%?

em - очень плохо, пришли новые правки, мы например меняем размер шрифта родителя и едут шрифты внутреннего контента. Тут думаю все понятно.

про rem можно если вы сможете дробно подлить все размеры

Единица rem задаёт размер относительно размера шрифта элемента <html>.

например базовый шрифт 16px

h1 - 38px

h2 - 20px

h3 - 18px

16 собственно 1 rem

тогда

h1 - 2.37rem

h2 - 1.25rem

h3 - 1.125rem

если для вас норм писать такие значения и потом в них не путаться, то ок,

или например придется изменить базовый шрифт в<html> для конкретной страницы, то все ваши h1 h2 h3 поедут и не будут соответствовать дизайну.

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

немного изменил описание для понятности

В прожектах у которых все элементы кастомные с возможностью принимать любую логику и формы, используя bootstrap и прочие ui системы, вы скорее всего будете обвязывать их дополнительными обертками и костылями, при этом неся за собой неиспользуемый функционал в виде js и style кода. Поэтому в проектах с индивидуальным визуалом рекомендую этого избегать и кастомизировать все под свои нужды. Часто в том же bootstrap бывает много того, что нам не нужно использовать и мы часть вырезаем а другую кастомизируем. Еще проблемы могут быть при изменении ui библиотек используемых в фраемворках. Если bootstrap или любые длугие ui системы легко применять под ваши договоренности и не требуется сложная кастомизация, вы можете использовать его без каких либо проблем.

часто приходилось видеть в проектах кастыли над бустрапом, поэтому такое мнение.

Дизайнер как раз должен учитывать ситуацию переполнения контента, и не задавать паддинги не вижу смысла по причине ниже

"ситуацию переполнения контента" - согласен, тут от проекта к проекту все может быть по разному

тогда можно пойти след путем

допустим высота кнопки по дизайну 48px, а шрифт 16px задаем след стили, предполагая что кнопка может быть c переносом шрифта в 2 строки

  max-height: 64px; // высота кнопки + высота шрифта
  min-height: 48px;
  padding: 8px 16px;
  font-size: 16px;

обычно это кейс редкий (текст кнопки в 2 строки) , но если и делать такое, то наверное следующим путем. Опять же неправильное вставание иконки или лоадера могут сломать высоту равную 48px. Поэтому я думаю если и использовать это для конкретного места, то писать дополнительный класс. Если по дизайну минимальная высота допустим 48px, а высота может быть любой то max-height вовсе не нужен, но в своей практике такое не встречал.

skeevy 7 мар 2022 в 12:03

если для вас норм писать такие значения и потом в них не путаться, то ок

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

обычно это кейс редкий

в этой кейсе лично я бы оставил только минимальную высоту и в том же rem, т.к. в идеальных условиях будет выглядеть так, как надо, а в иных случаях будут работать связки rem + rfs. Скорее всего у меня в этих случаях не вылезет текст за кнопку и в большинстве нетривиальных кейсов пропорциональность будет более-менее соблюдена

jtape 7 мар 2022 в 16:17

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

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

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

skeevy 7 мар 2022 в 21:55

что мы получим по факту

по факту мы получаем при правильном системном подходе построения типографики несколько строк css для построения адаптива, который сохраняет принципы поточности, задуманные дизайнером. Например, это хорошо видно тут. Вы получаете не только DX (developer experience) в виде построения адаптива, но и отзывчивый UX к масштабированию.

ведь по сули используем те же px в миксине, а визуально нечего не меняет. можете дать комментарий?

Этот миксин всего лишь DX. Пиксель это та единица, которая понятна всем. Пиксель статичен. EM/REM уже относительные единицы и ими оперировать сложнее.
Миксин позволяет выставить базовый контекст, которым может отличаться от 16 пикселей и указывая размеры, rem будет обозначен относительно контекста. Если у вас контекст, например, 10 пикселей, а шрфит - 16, то вы получаете 1.6. Поменяв контекст, вы получите 1, при этом менять типографику вам не нужно от слова совсем (на случай важных правок)

ы делаем размеры шрифта зависимыми от размера экрана. что может создать проблемы с восприятием чтения читателем

ваш дизайн обязан строго соответствовать макетам. Для остальных случаев нужен rfs, чтобы не ломать поток. У вас, например, макеты для 320-380, 768, 1360+ пикселей, при этом есть особые виды пользаков и клиентов, которые любят проверять адаптив, изменяя размер окна бразуреа. Я, когда работаю на своем маке самом свежем, часто пользуюсь сплит-скрин режимов до 4х окон и есть сайты, которые уже на полэкрана выглядят просто ужасно, потому что там все прибито гвоздями по пикселям, и расползаются и кнопки, и заголовки, и изображения теряют соотношения сторон, потому что верстальщику/фронтеру было лень добавить немного для того, чтобы во внештатных брейкпоинтах все выглядело более-менее чинно. И меня, будучи верстальщиком, некоторые заказчики этой историей так же выбешивали, и вот до чего я дошел, по сути, и по сей день использую в своих проектах. Если у вас шрифт будет чуть меньше того, что задумал дизайнер на внештатном разрешении - это не страшно, страшно когда он остается такой же и скорее всего он будет ломать поток.

Есть, например, вот такая статья, которая "поясняет за rem/em" и другие стороны доступности и адаптивности, есть куча других докладов на smashing magazine (тык, тык), css tricks (тык, тык) и т.д., и тот же Вадим Макеев что-то про шрифты и относительные единицы говорил. И даже в приведенных ссылках ведутся дебаты по поводу надо или нет, но лично мои реалии таковы, что лучше перестраховаться