Comments 10
Очень жду второй части!!!
Прозрачность без rgba() — теперь можно писать rgb(255 0 0 / 0.5)
Ура, наконец-то! Теперь можно сэкономить аж целую букву a.
Всё вместе — CSS наконец стал удобным для цвета
Да не стал он удобным. Ну добавились свистоперделки для цветодрочеров, которым sRGB не хватает, ну ок.
А чего реально не хватает в CSS - это например конкатенации стилей, чтобы можно было не в хтмле писать богомерзкое style="alert color-red font-big", а прямо в цсс ".alert{...} & .color-red & .font-big"
Быстрые трюки с относительными цветами
Вы можете динамически менять компоненты цвета — например, создавать более светлую или более тёмную версии
Идея относительных цветов: берётся существующий цвет, и на его основе создаётся новый.
Отлично подходит для создания оттенков, теней и фоновых цветов
Так кто создавать-то должен - разработчик, или дизайнер?
Для большинства разработчиков работа с цветами в CSS часто сводится к тому, чтобы просто скопировать значение из файла дизайна и вставить его в редактор.
Со всеми этими новыми цвето-фишками - флоу вроде и не поменяется.
Допустим, есть макет тоста. Да у него там какой-то базовый цвет, относительно базового - цвет рамки, цвет шрифта и т.д. Ок, что дальше? Разработчик должен угадать какой является базовый цвет, а потом через новые css-функции подбирать относитльные цвета? или как должно быть?
По-моему это всё должен делать именно дизайнер. А разработчик копирует цвет из макета и вставляет в код. А что там попало в буфер обмена - hex, или относительный hsl - про это должен позаботиться дизайнер (создатель) макета и всей палитры.
Если нужно сверстать конкретный макет - скорее всего так и будет, цвета просто копипастятся. Но если мы разрабатываем дизайн-систему, там палитры (и базовая, и семантическая) могут генерироваться каким-то алгоритмом, а не натыкиваться пипеткой. Логично держать этот алгоритм в кодовой базе.
Тут конечно можно спросить, а почему именно css, а не препроцессор, ведь излишне тащить это в рантайм? Но это философский вопрос, и на него нет однозначного ответа.
Кто именно эту задачу делает? Скорее всего, это будет какой-то человек "на стыке". Дизайнеры с навыками программирования существуют. И наоборот тоже.
Но если мы разрабатываем дизайн-систему
Так а кто ж её по факту разрабатывать изначально будет? Дизайнер же. Вот он её "разработал". Условно в фигме появляется страничка "палитра-нашего-бренда". Дальше что? Тоже самое - протыкали все цвета пипеткой, загнали в css-переменные, и пошли дальше работать. А не выдумывать - а как же мне закодировать цвет, через hsl, или mix-color, или ещё чёрти-как.
Дальше, условно делаем компонент кнопки. Видим - что она юзает несколько цветов из палитры для разных состояний. Ну так взяли, и описали это в стилях этой кнопки ссылаясь на переменные из палитры.
Вцелом, мой поинт в том, что обычному линейному разработчику, вникать в принцип построения палитры, при этом помнить где там базовый цвет, а где относительный, и по какому алгоритму высчитывается относительность - нет никакого резона. Это дело дизайнера.
Вот он её "разработал".
Суть в том, что разрабатывает он её не ручным ползаньем по колор-пикеру в фотошопе или фигме. А в самой палитре есть некая система и алгоритмы. Плюс в некоторых случаях сами палитры могут быть динамические (темизация и вот это всё). Ну и кто бы ни был тем человеком, линейный он или ортогональный, он использует какой-то код.
Например
https://m3.material.io/styles/color/system/how-the-system-works
Суть в том, что разрабатывает он её не ручным ползаньем по колор-пикеру в фотошопе или фигме. А в самой палитре есть некая система и алгоритмы.
Да я ж не против. Конечно же там есть (должна быть) какая-то логика в этих цветах. Я 15лет назад сам был дизайнером.) И всю эту науку по цветам, шрифтам, композиции - читал ещё в книжках.
Я про то, что разработчику-то нет смысла вникать в эту "химию". Он получил макет, в котором уже всё это продумано (должно быть продумано). Его задача перенести это в код. И вот при старте проекта, когда он открывает страничку дизайн-системы нового проекта в фигме - он эту систему копипастит себе в условно "базовые" переменные. Что попадает в переменные - hex, hsl, color-mix - без разницы. Дальше он уже оперирует этими переменными при создании компонентов.
разработчику-то нет смысла вникать в эту "химию"
Ну смотря какому. Прикладному, который использует готовые компоненты - наверное, не надо. А тому, кто поддерживает ДС - почему бы и нет. Или как минимум некоторым из них.
В крупных компаниях ДС - это отдельный крупный продукт, которым занимаются прям специальные команды. И там нет состояния "всё окончательно продумано" - оно живет и меняется.
Прагматичное руководство по современным цветам в CSS — часть первая