Comments 15
красаучег, люблю порядок
[name]_container — более спокойный вариант цвета, для второстепенных действий или поверхностей. Пример: primary_container;
А почему в нем используется "контейнер"? Будто бы сбивает с толку, если речь не про контейнер. Или реально речь про контейнер (цвет праймари контейнера/карточки), просто описание неудачное? 🤔
Это нейминг из material design, контейнер — это что-то вроде surface, но содержит больше цвета и чаще относится к более небольшим элементам (кнопкам, например), хотя может и к карточкам, в редких случаях. Отличие от основного цвета в том, что это более спокойный, нежный цвет (с более высоким значением lightness). В теории можно было бы назвать primary_surface, но мне container кажется более понятным, во многом за счёт узнаваемости у всех, знакомых с md2/3
А, понял. В md2 не было container цветов, появились только в md3, поэтому они у меня совсем вылетели из головы ) Но нейминг, как мне кажется, всё равно неудачный у них. Я такие цвета называю обычно [name]_alt или [name]_variant (в md2 раньше такое было, в md3 депрекейтнули), а можно вообще [name]_surface и on_[name]_surface (как понимаю, именно эти нейминги заменили на [name]_container и on_[name]_container в md3, а surface оставили только для названия базовой поверхности)
В создании компонентного уровня нет ничего сложного, зато он даёт много гибкости в системе. И если его не сделаете вы, его сделают разработчики у себя в коде. И вы будете только догадываться, что там происходит.
Разве разработчик не может использоват просто также семантический уровень? Зачем плодить лишние переменные для одного случая использования? Или я что-то не знаю (может, это обязательное ограничение платформы? кстати, какой?)
Получил такую инфу от прошлых мобильных разработчиков, после это мне подтвердили ещё трое, как iOS, так и Android. Почему они делают именно так, а не напрямую используют семантику я не знаю — как-то не подумал уточнить :—)
мне кажется можно любую базовую семантику подключить к любому проекту путём логического переопределения в нейминге, допустим: designer_primary -> project_primary -> programmer_primary -> platform_primary (ОБРАЗНО)
нет смысла каждого дизайнера УЧИТЬ подстраиваться под каждого программиста, а уж НЕДОдизайнера, которому лишь бы бабок рубануть за композицию, которая радует глаз клиента, ТЕМ БОЛЕЕ
Я правильно понимаю, что surface в основном служит для фонов и заливок? А как обрабатывать обводки? Каким уровнем токена?
Классный гайд, хотелось бы подробно и понятно еще и про Variables!
Пасиба за коммент!
Про Variables это про саму фичу в фигме? Мне кажется, что я лучше самой фигмы про это не расскажу → https://www.figma.com/community/file/1234936397107899445/variables-playground
Это в целом лучший способ изучить любую фичу в фигме, проходишь по шагам всё и готово.
(если трудности с англ, можно поставить QTranslate и переводить всё по сочетанию клавиш)
А мы не создаем отдельную группу для текста и его оттенков? То есть primary-цвет с уменьшенной lightness и будет основным цветом текста? А в Secondary будут его второстепенные оттенки?) Запутался немного)
А зачем группа для цвета? Если у нас текст лежит просто на поверхности, то это on_surface или on_surface_variant, если он интерактивный, то это primary или secondary.
Тут в целом подход такой, что мы не от элементов (текст, обводка, иконки и тд) отталкиваемся, а от сценария использования (более важный ли этот элемент на экране)
Спасибо за текст! Веру в хороших дизайнеров восстановила 🥹 это так хорошо, что расплакалась
Токены цвета для приложения: Как создать, использовать и передать в разработку