Комментарии 12
А для размеров не заводите переменные в верстке? Что-то типа:
--unit: 1rem;
--unit-half: .5rem;
--unit-small: .25rem;
И как боретесь с тем что для светлой и темной тем не всегда удается сделать однозначное переписывание цветов, а требуются дополнительные?
Размеры задаются через приписку L/M/S. Для мобилок добавляю XS.
С фронтендерами все соответствия обговорены. Плюс, они стали активно использовать Dev-режим. Больше вопросов не задавали )
По поводу светлых/тёмных тем. Названия цветов не привязаны к цветам (сказанул :). В итоге смысловая кодировка спокойно работает в обе стороны. Собственно, затем так и сделано.
Дополнительные цвета с фронтом обсуждали. Цвета не понадобились ) Часть светлых фонов решили через 50% прозрачность. Остальное вписалось.
Я про то, что для некоторых случаев может потребоваться цвет, которого в другой теме нет вообще. Сходу не смогу привести пример адекватный, но что-то типа такого: пусть есть цвет фона, на него кладем панельку с цветом подложки, а поверх нее надо будет вывести popup с всплывающем меню. Так вот для popup в светлой теме может быть background такой же как и у фона - белый, но за счет тени все будет нормально выделяться. Для темной же темы это не годится т.к. тень уже недостаточна, делать цвет как у фона - будет смотреться как дыра, цвет как у панели - сольется с панелью. Значит или заводить еще один цвет или делать обводку. Обводка - не всегда хорошо, т.к. для светлой темы она не нужна. Ну и т.п.
Вопрос, на самом деле, хороший. И я добавил в прошлом месяце дополнительный стиль SurfaceVariant.
Но, во-первых, прямо чёрных фонов в тёмных темах не бывает - это очень напрягает глаза. Во-вторых, для подложки попапов практически всегда используется более светлый оттенок.
Вот его я и вывел в отдельный стиль.
То что я назвал его черным, не значит что он #000, просто он самый темный, так что не суть важно. Я к тому веду, что вариантов может быть слишком много и в конечном итоге это приведет к тому что вся красота минимализма, обычно, разваливается. Возвращаясь к popup - в нем надо красить disabled альтернативы, выделять hover альтернативу, красить иконки у пунктов в выбранном/задизебленом/обычном варианте и т.п.
Я в своей библиотеке компонентов начал с того же, что и вы - решил что смогу определить базовый набор цветов, который буду применять ко всем компонентам. А когда понадобится темная тема, просто переопределю их.
На практике так не работает. Простое переопределение всегда ведет к компромиссу между нормальным дизайном и удобством разработки.
В конечном итоге я пришел к тому, что почти у каждого компонента есть собственный набор css-переменных, которые по умолчанию используют некий базовый набор цветов (также определенный в переменных), но могут быть переопределены на более глубоком уровне для конкретного компонента в конкретном окружении.
Да, понятно, что чёрный - это условный чёрный )
Ховеры у меня решаются через Primary Variant для кнопок. Для инпутов - через Primary. Часть - через прозрачность. Больше времени уходит на подбор оттенков, но вцелом работает.
Тут структура системы не меняется - только дополняется. И упор был на быструю перекраску. То есть проще в коде решить особо сложные моменты, но максимально не менять набор цветов.
Плюс, это же всё тянется потом на мобилку. С мобильщиками аналогичная схема собрана и работает. Только без ховеров, конечно )
Сталкивался с таким, но встречается это крайне редко. Решается это добавлением новой семантики цвета, как и всегда. Для "парящих" элементов с тенью можно заводить отдельный стиль цвета, surface-elevated, например. Где нет тени, использую просто цвет "surface", даже если hex у них одинаковый. Ну и в темной теме тень отключается, а цвет фона задается произвольный.
В таком подходе всегда смущало повторение одного цвета в разном контексте.
Например, имеем красный цвет. Применяется к кнопке, тексту, бордеру, бейджу и список не конечен. Итого 4 переменные на один цвет, под один контекст не загонишь.
Теперь состояние элементов – hover и click (напр), для которых тоже красный, но немного другой красный (оттенок), тоже по 4 состояния в разном контексте. И конечно темная тема.
Как итог, огромное количество повторяющихся переменных. Группировка и покраска элементов в макете усложняется банально поиском "куда чего". А процедура замены красного на "чуть светлей" (и вытекающих из него оттенков) превращается в легкий гемор.
Такая структура выбрана именно для быстрой перекраски. Потому что маркетплейс платформа копируется в новый проект, адаптируется под фирменный стиль и разворачивается гораздо быстрее, чем раньше.
Потому что тот же красный используется и для ошибок и для статусов. Если просто поменять красный на условный синий, вся логика поедет ))
Книга «Дизайн маркетплейса». Гамма и стили