Почему P3-цвета станут «новой ретиной», которую мы все будем должны поддерживать.
Как мы будем указывать цвет в CSS в 2022—2023.
Краткий пересказ:
1. В CSS мы будем указывать два набора цветов — расширенные P3-цвета и цвета для старых мониторов. 2. Цвет будем писать lch(36% 81 200 / 50%) — без запятых, альфа через черту, через функцию lch().
Начнём с P3-цветов.
Современные экраны недавно научились показывать гораздо больше цветов. И таких мониторов уже очень много — большинство техники Эпл, телефоны на Андроде с OLED-экранами.
Но что делать с кучей новых цветов?
Китайский Андроиды просто растянули старые sRGB-цвета на новое большее пространство.
Плюсы: всё стало более сочным, ничего не надо менять.
Большой минус: цвета поменялись и выглядят не так как задумывал дизайнер.
Поэтому серьёзные компании не хотят просто растягивать старые цвета на новые, а хотят более осознанный подход с новыми цветами — чтобы разработчики явно указывали новые цвета в приложении.
Тут главным локомотивом изменений является Эпл.
Но нужно решить 2 задачи:
1. Нужно договориться о минимальном наборе новых цветов.
Кажется на ближайшие годы таким набором будет P3.
Текущий (старый) набор называется sRGB.
Но обратите внимание, что глаз видит больше цветов, поэтому P3 — не финальное слово. Потом будут новые экраны за границами P3.
2. Нужно дать API, чтобы проверить набор цветов в экране, и способ указать расширенные цвета (rgb() и hex-цвета могут кодировать только старые sRGB-цвета).
В CSS для первого будет меда-выражение color-gamut. Для второго будет много способов, но мне кажется победит lch().
Мне кажется, что внедрение P3-цветов будет напоминать внедрение «ретины».
Оно будет идти быстро, так как выгодно бизнесу — у богатых клиентов ваш сайт будет выглядеть сочнее, чем у конкурентов.
Но нужно будет иметь 2 набора цветов (или генерировать старые цвета при сборке).
P3-цвета сейчас поддерживает множество техники Эпл, андроиды и ноутбуки с OLED-экранами.
Мне кажется, будущее за lch() даже если вам пока не нужны P3-цвета.
hex и rgb()/rgba() точно не подходит. Кроме того, что они не поддерживают P3-цвета, они ещё неудобны.
Читая значения нельзя понять, что два цвета имеют один оттенок, просто разную яркость.
hsl() решает проблему с удобностью, но, кроме отсутствия поддержки, имеет фундаментальную проблему — l-компонент не передаёт яркость как её видит глаз.
Цвета в разных оттенках, но с одним значением яркости для глаза будут иметь разную яркость.
Почему HSL неправильно передаёт яркость? Дело в том, что глаз видит разное кол-во цветов разных оттенков. В итоге нельзя сделать простой куб возможных цветов.
HSL растягивает сложную форму видимых цветов в куб. В итоге поле получается неравномерным.
LAB-цвета через lch() и lab() мне кажутся лучшим решением для CSS будущего:
— В отличие от HSL, яркость передаётся правильно.
— Могут кодировать не только P3-цвета, но и все цвета видимые глазом. То есть в далёком будущем, где экраны будут лучше P3 мы тоже сможет работать с LAB.
Но у LAB-цветов есть одна проблема. Играясь в отдельными параметрами можно вывести цвет за пределы возможностей экрана или даже пределы возможностей глаза.
Помните, LAB в отличие от HSL не растягивает видимые глазом цвета и двигаясь «вбок» можно выйти за пределы глаза.
Обе CSS-функции lab() и lch() кодируют цвет в одном пространстве, но через разные координаты. lab() — декартова (x, y), а lch() — полярная (расстояние от центра и угол).
Я считаю, lch() удобнее так как угол близок к понятию насыщенности, а длина — оттенок.
У lch(36% 81 200 / 50%) другой формат аргументов. Нет запятых, альфа-канал через / и без отдельной функции lcha(), как rgba().
Это новый синтаксис, который добавили и для rgb() и hsl(). Просто сахар для удобства и снижения описок.
lch() не будет поддерживать старый формат.
В новом формате аргументов у lch(), rgb() и hsl() альфа-канал можно указывать в процентах вместо числа от 0 до 1. Для свойства opacity тоже добавили проценты.
Мне кажется этот формат логичнее, так как в графических редакторах полупрозрачность слоя тоже идёт в процентах.
Кроме просто указания цвета, система кодирования цвета влияет на рассчёт градиента.
Сейчас в синтаксис градиентов хотят добавить опцию считать его через LAB, так как получается красивее, без скатывания в серый посередине.
Для разработки ещё важно кодирование цвета в файлах изображений.
Но там поддержка других цветовых пространств есть давно и я оставляю эту тему вне этого треда.
За пределами треда остаются CSS-функции трансформации цвета, которые очень нужны при использовании динамических цветов через CSS Custom Properties.
Там пока нет договорённости.
Что с поддержкой новых дисплеев в ОС и lch() и нового формата в браузерах?
Тут всё пока плохо. Новые цвета работают только в Safari.
Интересно, что в DevTools будет показываться безопасная граница старых RGB-цветов.
Другие браузеры и ОС тоже в процессе добавления новых цветов.
Но lch() можно использовать уже сейчас через PostCSS-плагин (входит в postcss-preset-env) для конвертации lch() в rgb(), конечно же, без поддержки P3-цветов. github.com/csstools/postc…
Я уже начал использовать lch() цвета через postcss-lab-function.
Через правила color-no-hex и function-disallowed-list в Stylelint можно запретить использовать старые функции, если хотите переходить быстрее. github.com/hplush/slowrea…
Про P3-цвета советую рассказать дизайнерам и вместе попробовать поэкспериментировать с ними под Safari в новом проекте.
С CSS Custom Properties это не сложнее, чем добавить тёмную тему.
Из этого треда я потом сделаю статью, поэтому поправляйте меня, где я неправильно использовал термины из теории цвета.
У @ariarzer есть хорошая статья про теорию цветовых пространств. Там более системно объясняются термины.
И даётся больше вариантов функций цвета в CSS, например hwb()
Если Реакт у вас просто UI-слой, то упрощается много вещей:
1. Тестирование. Тесты стейт-менеджера не требует эмуляцию DOM, а вся логика в стейт менеджере. А Реакт можно тестировать простыми Сторибуками. 2. Кросс-платформенность. Легко сменить UI на React Native или Vue.
Странно, что у нас заблуждение, что фронтенд — «лайт ИТ».
На самом деле это очень сложная область.
Очень много сложных задач, которые сейчас боятся решать в других областях (например, бэкенд).
1. На самом деле фронтенд — это распределённая система клиент-сервер.
Между узлами очень нестабильное соединение с большим latency.
Не всегда есть гарантия, что версия клиента соответствует версии бэкенда.
В современной теории распределённых систем — это очень сложный ад.
2. Среда исполнения полностью непредсказуемая. Кроме кучи браузеров ещё и поведение любого браузера может быть изменено расширениями или необычным железом.
Сравните это с предсказуемым докер-образом в бэкенде.
Жена подарила новый браслет-чётки для моего ключа YubiKey — цвета символизируют планеты Солнечной системы.
А на фоне NFC-приёмник, чтобы не разнашивать USB-разъём. Я часто пользуюсь ключом для GPG-подписи гит-тегов и чтения программой одноразовых aTOTP-кодов.
Мне любые браслеты не удобны. Эти чётки — аналог брелка. Делают ключ больше, чтобы не потерять, например, в ранце.
Заодно во время раздумий можно теребить как чётки.