Абсолютный минимум, который каждый разработчик должен знать про юникод

Никита Прокопов рассказывает:
- что такое юникод;
- почему иконка Apple в тексте показывается только на устройствах Apple;
- чем отличаются UTF-8 и UTF-16;
- почему шрифты лом�ются;
- что такое графемы;
- почему Твиттер иногда рисует русские тексты болгарскими символами.

https://tonsky.me/blog/unicode/

2023 JavaScript Rising Stars

Есть такой проект, в котором уже восьмой раз собираются тренды из мира JavaScript по анализу звёздочек на GitHub за последние 12 месяцев. И в этом году снова интересные результаты.

- Среди всех проектов победил shadcn/ui — библиотека React-компонентов со стилизацией на Tailwind CSS.
- На втором месте Bun — тулкит для всего, который в сентябре прошлого года был залайкан неприличное количество раз. В 2022 году он был вообще на первом месте.
- На 3 и 4 месте утилиты для рисования и вайтбординга в браузере Excalidraw и tldraw.
- Среди фронтенд-фреймворков выделяется htmx — программирование на html-атрибутах. Пока только второе место, но React догоняет уверенно.
- В бэкенде всё ещё впереди всех Next.js, несмотря на все интриги и критику сообщества.
- В мобильной разработке лидирует Expo. Про него не слышал, но он смог совсем чуть-чуть, но всё же обогнать React Native по звёздочкам. В 2022 году он был далеко на втором месте.
- Для стилизации самое большое количество звёздочек у Tailwind CSS.
- Для тестирования большинство людей выбирают Playwright.
- Появилась отдельная категория для AI-библиотек.
- Пропала категория GraphQL, уже не в тренде.

Видно, что многие инструменты как были популярные несколько лет назад, так и остаются популярными. Однозначно на количество звёздочек влияет маркетинг — можно сопоставить на графиках резкие скачки и громкие анонсы. И круто, что появляются новые хайповые библиотеки — это в любом случае полезно для рынка.

https://risingstars.js.org/2023/en

Редактор CSS, написанный на CSS

Вчера наткнулся на «тут» Мириам Сюзанн, где она показала интересный способ сделать редактор CSS на самом CSS. Идея не совсем уж новая, Лия Веру давно в своих презентациях пользуется чем-то похожим, но захотелось реализовать такой редактор самому.

1. Для тега style можно выставить display: block, тогда браузер отрисует его содержимое.

2. Добавляем атрибут contenteditable, чтобы можно было редактировать это содержимое.

3. Добавляем ещё один атрибут spellcheck="false", чтобы браузер не проверял наш CSS на грамматику. Я и так знаю, что CSS — не английский язык.

4. Применяем свеженький @scope, чтобы стили применялись только внутри нашего компонента. Увы, работать из-за этого будет только в Chrome пока, но это же для демок, не для продакшена.

5. Добавляем нативную тёмную тему при помощи color-scheme: dark, чтобы глазкам было приятно.

6. Оборачиваем в CSS-контейнер, чтобы можно было встраивать демку в страницу.

Получаем нативный простенький редактор CSS с адаптивностью, поддержкой тёмной темы и не требующий никаких библиотек. 54 строчки CSS с пробелами.

https://mefody.dev/chunks/css-editor-in-css/

Интересный случай с селекторами

София Валитова разбирает важную особенность работы :has() в CSS.

https://ru.ariarzer.dev/2024/notes/is-inside-has/

Workflow и Визуализация рабочих процессов

Видео выходного дня. Доклад Алексея Пименова про то, как можно работать с тикетами на рабочей доске, чтобы и команде было удобно, и заказчикам понятно.

Мысли, которые выписал себе на проработку:

1. Визуализация должна отражать текущие процессы в команде, а не то, как мы должны делать. Иначе будет и сопротивление команды, и вакханалия в анализе спринтов. Команде нужно продать какие-то изменения.

2. Изменять воркфлоу можно и нужно. Потому что п.1.

3. Для разных участников процесса можно сделать разные доски. Например, для команды разработки, если они никак не погружены в дизайн (для примера), шаги про дизайн можно спрятать. А дизайнерам не показывать деплой и релизы. К сожалению, не все инструменты позволяют такое настраивать, приходится выдумывать костыли. Notion умеет, но его часто нельзя использовать в корпоративной среде.

4. Хорошая визуализация помогает находить проблемы. И эти проблемы стоит обсуждать с командой.

5. Не нужно проводить стендапы так, чтобы каждый участник рассказывал по очереди, что он вчера делал и что будет делать сегодня. Идти нужно по доске справа налево (или слева направо, что вам важнее). Тогда вы будете обсуждать фичи, которые важно сделать, не теряя контекста при переключении между людьми. Тоже стараюсь такое внедрять в командах, но иногда встречаю сопротивление микроменеджеров, которые зачем-то следят, кто и что делает, чтобы вдруг никто без работы не остался.

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

https://youtu.be/jQlNg_exE48

Встраивание SVG в CSS

Иногда возникает необходимость вставить SVG-картинку инлайном как значение какого-нибудь свойства в CSS. Например, иконки как фоновые картинки, когда мы пишем background-image: url('data:image/noscript+xml;base64,A1B2...C3=').

Стоян Стефанов напоминает, что почти все браузеры (кроме старых вроде IE), нуждаются в кодировании всего 3 символов: <, > и #. Поэтому делать полноценный base64 точно не нужно — это не читаемо, не редактируемо, раздувает бандл. Дайте gzip делать его работу.

У Юли Бухваловой есть готовый инструмент под такое: https://yoksel.github.io/url-encoder/. В нём преобразуется большее количество символов, но зато более надёжно.

https://www.phpied.com/truth-encoding-noscript-data-uris/

Что сегодня умеет PWA

Нашёл интересное приложение, которое использует различные полезные API для PWA с примерами кода. Причём это приложение само по себе PWA. Здесь есть использование нативного шаринга, записи звуков, захвата экрана, работа с NFC, AR/VR, синтез голоса и так далее. К сожалению, некоторые примеры у меня ломаются на устройстве, но можно завести ишью на GitHub, автор проект поддерживает.

Ну и напоминаю, что у меня тоже есть полезное приложение: https://mefody.github.io/fugu-detector/. На страничке — список различных Fugu API, причём можно посмотреть, работает это API в вашем браузере или нет. Недавно Томас Штайнер помог синхронизировать эту страничку с его обновляемым списком Fugu API.

https://whatpwacando.today/

Как определить, что браузер может установить PWA

Некоторые сайты хотят, чтобы их установили как PWA. И это нормально, учитывая, что в разных браузерах по-разному нужно найти правильные кнопки, чтобы иконка вашего любимого сайта всё-таки появилась у вас на рабочем столе. В Safari, на мой взгляд, установка PWA совсем уж неочевидна. Но показать кнопку Install хочется.

Определить, что браузер умеет в установку, в принципе, можно. Например, проверить поддержку метода getInstalledRelatedApps. Или посмотреть на window.BeforeInstallPromptEvent. Но только не в Safari.

Глеб Хмызников показывает, как для веб-компонента pwa-install, который как раз и показывает всплывашки с инструкциями по установке для разных браузеров, пришлось костылить определение, что мы находимся в версии Safari, которая всё-таки умеет в Web Apps (как называют PWA в Apple). И это старое доброе выискивание косвенных признаков. Мы знаем, что Web Apps доступны в Safari 17. А ещё мы знаем, что в Safari 17 есть WebGL внутри OffscreenCanvas. А ещё в нужной нам версии есть новые возможности воспроизведения аудио. Получаем определение нужной нам функциональности через косвенные знания о релизах браузера.

И, к сожалению, это не временное решение. Даже если в следующих версиях Safari появится JavaScript API для нормального определения, старые версии придётся поддерживать достаточно долгое время.

https://blog.pwabuilder.com/posts/web-apps-on-macos-sonoma-got-a-proper-install-experience/

Как разместить div в центре контейнера

Типичный вопрос с собеседований по вёрстке. Джош Камю делится шестью современными способами, когда размеры элемента не известны заранее. translate(-50%) как будто уже в прошлом.

https://www.joshwcomeau.com/css/center-a-div/

Подсветка кода на странице при помощи Custom Highlight API

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

Брамус показывает, как можно применять современный Custom Highlight API, чтобы не создавать span для стилизации в принципе. Это такая апишка, которая уже работает в Chrome 105 и Safari 17.2. И она позволяет при помощи JavaScript разбивать текстовые узлы на набор параметризированных токенов. Как это делать в JS, лучше смотреть в самой статье. Но зато в CSS всё становится сильно приятнее:

::highlight(important) {
    color: red;
    font-weight: bold;
}

::highlight(attr) {
    color: violet;
}

Имена хайлайтов как раз задаются в JS.

Понятно, что каждый день такое писать не придётся, и скорее всего библиотеки начнут рано или поздно применять эту апишку, так что можно будет продолжать использовать их. Но в целом подход интересный, с ним можно делать разное: кастомный поиск текста на странице с синонимами, выделение связанных блоков текста, акцентирование внимания на чем-то на странице в зависимости от действий пользователей, например.

https://www.bram.us/2024/02/18/custom-highlight-api-for-syntax-highlighting/

Bloom-фильтры

Представьте, что вам нужно принимать решения на основе какого-то набора исторических данных. Пусть вы делаете систему кэширования, которая должна срабатывать только для тех страниц, к которым уже обращались больше 1 раза, чтобы экономить дисковое пространство, но помогать перфомансу. Решение в лоб — хранить список посещённых пользователями страниц, добавить к списку счётчик. Но с таким решением есть две важные проблемы:
1. Сам список в какой-то момент начнёт весить неприлично много.
2. Время поиска по такому списку либо начнёт расти с ростом списка, либо придётся прикручивать какой-то умный индекс, который начнёт тормозить не чтение, а запись.

Сэм Роуз объясняет, как работает интересная структура данных BloomFilter, решающая эти проблемы. Если вы готовы принимать ложно-отрицательные решения в 1% случаев, то можно значительно сократить и размер списка, а время поиска по нему. И для примера выше это то, что надо: 1% ложных кэширований не сильно повлияет на затраты на дисковое хранилище, если вы при этом экономите на размере списка больше 80%.

Если любите интересные структуры данных — статья вам понравится.

https://samwho.dev/bloom-filters/

Определение поднабора для шрифта

По статистике HTTP Archive на 81.5% сайтов из топ-миллиона используют как минимум один веб-шрифт. Веб-шрифт — это который подключается как внешний ресурс, не локальный шрифт пользователя. При этом шрифты сильно влияют на загрузку страницы.

Пол Кальвано собрал полезный инструмент Web Font Analyzer, который смотрит на реальную загрузку страницы, какие шрифты на ней используются и как сильно они влияют на метрики Core Web Vitals. Для этого нужно сначала проанализировать страничку на webpagetest.org, а потом результат анализа скормить в сам Web Font Analyzer.

Посмотрел на свой блог, взял специально статью с примерами кода. И получилось, что всего страница до FCP грузит 43 КБ, из них 36 КБ (84%!) — Fira Code для сниппетов кода. При этом глифов на странице используется 87, а внутри шрифта их 536.

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

https://paulcalvano.com/2024-02-16-identifying-font-subsetting-opportunities/

keyux

Андрей Ситник выпустил библиотеку, помогающую удобнее работать с сайтом при помощи клавиатуры. Под капотом работает с ARIA-атрибутами, то есть если вы изначально доступно размечали комбинации клавиш, то библиотека сработает как прогрессивное улучшение.

Кроссбраузерно, фреймворко-агностично, в сжатом виде всего 1 КБ, без зависимостей, с отличной документацией прямо в Readme проекта.

https://github.com/ai/keyux

Интерактивный гайд по :has()

Ахмад Шадид в очередной раз выдал супер-подробный гайд. На этот раз про то, как работает родительский селектор :has(), с полезными примерами.

Что можно подсмотреть:
- Как правильно делать boolean-логику на основе has().
- Как радикально менять разметку на основе количества вложенных элементов (например, когда мало карточек — растягивать их на всю ширину, а когда много — рисовать плотно и колонками).
- Как делать фолбеки, если какого-то элемента нет (например, когда картинка товара есть — рисуем картинку, а когда нет — заранее подготовленный placeholder).
- Как изменять размеры контейнера на основе его содержимого (для маленьких виджетов резервировать поменьше места на сам контейнер в раскладке, для больших — побольше).
- Как сделать всплывашки и попапы, которые не перекрывают друг друга (очень хороший пример про GDPR-баннер и иконку чата с поддержкой, которые на большом количестве сайтов друг другу мешают).
- Как научить панель управления с кнопками визуально реагировать на наличие особенных кнопок внутри.
- Как сделать зависимые друг от друга инпуты (например, если значение select требует уточнения, рисуем инпут для этого уточнения).
- И многое другое.

Примеры из списка сразу хочется сделать на каком-нибудь React: затащить на клиент логику показа компонента в зависимости от пропсов, перерендерить при необходимости. Но в этом и огромное преимущество :has() — ему не нужны фреймворки. При помощи этого селектора и дисциплины в именовании классов можно творить самые настоящие «умные» компоненты без единой строчки JavaScript. А это и меньший клиентский бандл, и меньшее количество ререндерингов.

Напоминаю, что не стоит забывать про старые браузеры, которые в :has() пока не умеют. Но если ваш проект работает с вечнозелёными браузерами, то уже можно внедрять: https://caniuse.com/css-has.

https://ishadeed.com/article/css-has-guide/

Итак, что же на самом деле ломает Apple в ЕС?

Думаю, мимо вас не прошла новость о том, что с 6 марта 2024 года Apple обязаны обеспечить в Евросоюзе выполнение закона DMA, в том числе разрешить установку сторонних магазинов приложений и альтернативные браузерные движки. Официальный анонс можно почитать тут, а ещё мы в подкасте «Веб-стандарты» несколько раз эту тему обсуждали.

Так вот, Томас Штайнер, проживая в ЕС, собрал более-менее точный список того, что сломается для пользователей iOS в Европе уже скоро:
- Push API. Оно доступно только для Home Screen web apps, а так как их больше не будет, то и доступа к API не будет. А ведь нотификации не только про зло, в разных приложениях они очень даже полезные.
- Badging API. То же самое, из-за привязки к Push API. Никаких чиселок на иконках веб-приложений.
- Режим standalone. Открываться будет в браузере, спрятать панельник браузера теперь никак не получится, никакого нативного опыта.
- Хранимые данные. Напомню, в Web Apps данные для каждой «иконки » сохранялись в своё изолированное хранилище. И если до 6 марта оно было чем-то наполнено — се ля ви, логиньтесь заново, вносите данные с нуля.
- Несколько ярлыков для одного и того же Web App. Я таким пользовался для разных аккаунтов твиттера, удобно. Данные ведь изолированы.

Не будем углубляться, кто прав, кто виноват, а кто разводит панику. Если ваши сайты умеют в PWA и пользуются популярностью в странах ЕС, будьте готовы к тому, чтобы ничего не упало из важной фунциональности. И купите техподдержке вашего сервиса поддерживающий пирожок — им придётся отвечать на много однотипных сообщений, что сервис «не работает».

https://blog.tomayac.com/2024/02/28/so-what-exactly-did-apple-break-in-the-eu/

«А разговоров-то было!»

Apple обновили страничку с подробностями про поведение iOS в Евросоюзе. И там появился новый ответ на вопрос «Why don’t users in the EU have access to Home Screen web apps?» в секции Q&A. И если коротко, то к ним поступили просьбы продолжить поддержку Web Apps в iOS, поэтому они вернут старое поведение в обновлении 17.4. Работать будет только в WebKit, остальным браузерам придётся пока подождать.

Про «вернут», конечно, интересно написали. По сути ведь ещё ничего не исчезло, оно в обновлении 17.4 и должно было пропасть. Но «ничего не изменится» не так хорошо для анонса звучит. Ну и «просьбы» — это полноценная петиция от Open Web Advocacy, но про неё тоже как-то не захотели в анонсе писать.

Короче, выдыхаем. PWA на iOS пока в безопасности. Когда шума много, можно чего-то достигнуть. А шумели и обсуждали не зря.

https://developer.apple.com/support/dma-and-apps-in-the-eu/

MinskJS Meetup #11

Если вы не знали, я ещё и минские митапы по фронтенду помогаю делать. И уже в эту среду (6 марта) в 19:00 (по минскому времени) у нас будет онлайн-митап MinskJS. Со спикерами делаем финальные прогоны, готовим трансляцию, а вы можете сохранять в закладки:
- программу митапа, https://telegra.ph/MinskJS-Meetup-11-01-19;
- ссылку на трансляцию, https://www.youtube.com/watch?v=lQmFPJUljNM.

В программе:
- «Апгрейд браузера с помощью Web Extension API», Александр Селиванов.
- «Создание виджетов на iOS с использованием JSX», Олег Поздняков.
- «Не учите алгоритмы, они не нужны!*», Полина Гуртовая.

Да, никакой регистрации. Просто приходите. Всех ждём 🙂

Что на самом деле делает атрибут decoding у img?

Сейчас будет сложно, а в оригинальной статье ещё сложнее, но когда-нибудь эти знания вам пригодятся.

Возможно, вы замечали, что иногда к изображениям зачем-то добавляют decoding=async. Возможно, вы даже сами добавляли такой атрибут по советам из статей по оптимизации перфоманса. А если вы пользуетесь компонентом Image из NextJS, то у вас в проекте точно по умолчанию для картинок включён этот атрибут. А он вообще важный?

Барри Поллард задался тем же вопросом и раскопал много интересностей, пообщавшись непосредственно с разработчиками браузеров.

Начнём с того, что у decoding может быть три значения по спеке:
- sync — просим браузер декодировать картинку синхронно;
- async — просим браузер декодировать асинхронно;
- auto — доверяем браузеру выбрать самостоятельно.

Пока понятней не стало. Но мы уже знаем, что у картинок есть этап декодирования. То есть когда браузер видит в коде страницы <img src='...'>, он сначала попросит сетевой кусок браузера сходить за картинкой в сеть или кэш, потом ещё один вспомогательный кусок попросит декодировать картинку (превратить из набора байтов в понятные для отрисовки данные, не просто так же кучу кодеков придумали сложных для сжатия), и только потом отрисует.

Парадокс в том, что на обычные статические страницы этот атрибут почти никак не влияет. То есть браузеры и так знают, что им важно пользователю показать контент как можно раньше, при этом не рисовать вообще каждое изменение, поэтому уже есть умные механизмы сбора изменений в отрисовке в чанки. И картинки не декодируются в основном потоке, так что JavaScript тоже с картинками за время основного потока не борется.

А ещё в Firefox по умолчанию у всех картинок применяется async. А у Chrome sync. А у WebKit в большинстве случаев sync, но для некоторых исключений всё же async. То есть сами браузеры до сих пор не договорились, какое поведение должно быть дефолтным.

На самом деле значительная разница появляется тогда, когда вы вставляете картинки при помощи JavaScript. А в современном SPA-мире такое сплошь и рядом. Джейк Арчибальд собрал демку, на которой в разных браузерах можно эту разницу заметить (ссылка в статье). Суть в том, что если внутри JS последовательно создать div с красным фоном, а потом внутрь него положить баааальшой img, загруженный через тот же JS, то в случае с sync случится подвисание страницы, потому что браузер увидит инструкцию декодировать синхронно и отложить отрисовку до окончания декодирования. А в случае с async вы сначала увидите красный фон у div, и только потом поверх нарисуется картинка, что тоже не ок, потому что моргание на экране.

А ещё браузеры шибко умные, поэтому картинки, которых внутри вьюпорта нет, не декодируются до тех пор, пока к ним не подскроллишь. Что в целом логично, память нагружать тем, что может и не понадобиться, как будто не стоит. Но если вы на странице с большим количеством картинок ближе к футеру нажмёте клавишу End на клавиатуре... получите подвисание.

В общем, после прочтения статьи хочется дать такие советы:
- Если вы и так загружаете картинки при помощи JS, то добавьте ещё await img.decode();. Эта конструкция всё равно асинхронная, зато перед отрисовкой будет всё готово, чтобы отрисовать быстро.
- async всё же предпочитетельнее для ситуаций, когда вам текстовый контент на странице важнее картинок. Будет два кадра отрисовки, но зато текст появится чуть-чуть раньше. На слабых устройствах это «чуть-чуть» будет заметно глазу.
- Для тонкого тюнинга Core Web Vitals, особенно LCP, пробуйте разное. Интуитивно кажется, что sync правильнее, чтобы не тратить время на лишнюю отрисовку, но браузер слишком умный, поэтому банально надо пробовать разное и сравнивать.
- Если вы занимаетесь тюнингом декодирования картинок на сайте, то либо ваш сайт уже идеален по перфомансу, либо можно заняться более полезными вещами, вроде ленивой загрузки и оптимизации самих картинок.

https://www.tunetheweb.com/blog/what-does-the-image-decoding-attribute-actually-do/

Держим <head> в порядке

Наткнулся на интересный скрипт, который позволяет провести очень быстрый аудит и относительно быстро починить порядок тегов внутри <head>.

Есть такой CSS-сниппет от Гарри Робертса, который подсвечивает неправильный порядок служебных тегов. Называется ct.css. И ещё доклад про этот сниппет. Гарри — очень крутой специалист по веб-перфомансу, к тому же слайды довольно убедительны.

Скрипт capo.js делает почти то же самое, только выводит результаты аудита в консоль. И даёт советы, как лучше отсортировать мета-теги, OG-разметку и прочее содержимое <head>, чтобы отдавать самое важное для быстрого отображения страницы сразу, а остальное попозже.

Попробовал запустить на нескольких сайтах — не врёт, и правда есть смысл внести правки.

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

https://rviscomi.github.io/capo.js/

Открытие файлов в веб-приложении

Думаю, все когда-нибудь делали набор действий «Правой кнопкой мыши — Открыть с помощью... — Какое-то приложение». PWA на десктопе тоже можно добавить в список приложений, при помощи которых можно открывать файлы определённого формата.

Ларс Кнудсен собирает веб-приложение, в котором можно просматривать файлы формата GeoJSON. По умолчанию они имеют расширение .geojson, собственно. И кажется логичным каким-то образом сказать системе, чтобы все файлы с таким расширением открывали это веб-приложение.

Для этого нужно сделать две вещи:
- Добавить в веб-манифест массив обработчиков file_handlers. Нужно указать, какой относительный URL открывать при открытии файла. И можно указать иконки, чтобы они в меню подставлялись рядом с названием приложения.
- При открытии PWA обработать window.launchQueue — именно сюда браузер сложит файлы, которые пользователь попытается открыть из операционной системы.

Я у себя похожее внедрял в своём D&D Tokenizer, чтобы любые картинки быстро передавать в PWA для рисования игровых токенов. Экономит время, удобно. А для всяких веб-плееров, которые умеют работать с локальными файлами, ещё и необходимо.

https://dev.to/denladeside/handling-files-in-enterprise-web-solutions-3mkc

Создание цветовых палитр при помощи CSS-функции color-mix()

Мишель Баркер очень подробно объясняет, как работает функция color-mix(). По сути при помощи неё можно смешивать цвета, только важно разобраться, как работает это смешивание.

Когда вы пишете color-mix(in srgb, blue, red), то по сути вы смешиваете синий и красный в соотношении 1:1. При этом смешивание — это интерполяция. Очень грубо говоря, для sRGB браузер возьмёт отрезок на градиентной цветовой плоскости между двумя точками, выберет середину, выдаст результат. Для пространств вроде oklch всё сложнее, но суть та же — у браузера есть правила интерполяции.

Для записи color-mix(in srgb, blue, red 10%) синего будет 90%. В сумме браузер попытается сделать 100%.

А вот с color-mix(in srgb, blue 10%, red 20%) случай интересный. Здесь суммарный цвет получится в соотношении 1:2, но непрозрачность цвета будет 0.3, потому что оставшееся до 100% заполняется прозрачным цветом.

Я бы эту функцию пока использовал только для смешивания с чёрным и белым. Смешивать цвета в sRGB всё ещё сложно с точки зрения предсказуемости — правила интерполяции там не очень. А вот когда oklch можно будет втаскивать в проекты, тогда уже можно начать играться с математикой цвета в более подходящем для этого пространстве. С CSS-переменными функция работает замечательно, так что можно на основе нескольких базовых цветов математически описать полную палитру для всех состояний.

https://developer.mozilla.org/en-US/blog/color-palettes-css-color-mix/