#ссылка дня

В комментариях к посту про моргающее меню а-ля macOS HIG всплыл вопрос: а есть ли вообще ресурсы, где можно подсмотреть, как одни и те же интерфейсные штуки сделаны в разных продуктах?

Есть как минимум два.

На самом деле их сотни были и есть, но почти все достаточно банальны. Я решил отобрать два из разных миров.

Refero Styles собирает стили реальных продуктов. Сейчас там уже больше 2000 примеров: цвета, типографика, отступы, компоненты и прочие детали. Причём всё это ещё и упаковывается в DESIGN.md, который можно скормить Cursor, Claude Code, Codex или чему-нибудь ещё и попросить делать «примерно вот так».

А The Component Gallery заходит с другой стороны: выбираешь конкретный компонент — tabs, accordion, popover, pagination — и смотришь, как он устроен в разных дизайн-системах. Сейчас там 60 типов компонентов, 95 дизайн-систем и больше 2600 примеров.

По сути, это та самая витрина компонентов, которая когда-то была одной из самых полезных частей Storybook Component Encyclopedia. Сам Storybook с тех пор ушёл гораздо дальше в сторону полноценной инфраструктуры для разработки, тестирования и документации, а простое «покажи мне двадцать разных tabs рядом» стало искать заметно сложнее.

Так что Refero — скорее про стиль целиком, Component Gallery — про конкретный паттерн. Для вопроса «а как вообще принято делать вот эту штуку?» оба отлично подходят.

#design #skill

#инструмент дня

Промо-видео на Rust. Что? Да!

Давно знал об FFrames — фреймворке, в котором видео описывается кодом: Rust отвечает за логику и анимации, SVG — за графику, GPU — за рендер. Но всё никак не доводилось попробовать.

Ну как, не доводилось... я не особо понимал, а что там делать и как. Но решился.

Попробовал на промо для своего пульта. Озадачил Codex нарезать скриншоты с эмулятора, дав полную свободу действий, и попросил собрать 15-секундный ролик.

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

На каждом кадре Rust пересчитывает эти параметры. FFrames рисует результат и собирает MP4. На Mac используется Metal.

Например, вот так заголовок плавно поднимается на место за полсекунды:

let y = frame.animate(&fframes::timeline!(
    at 0.0 => 0.5, animate 200.0_f32 => 120.0,
    fframes::animation::Easing::EaseOut,
));

fframes::svgr!(
    <text x="80" y={y} font-size="64" fill="#fff">
        "Всё есть код."
    </text>
)

Наш ролик: 886×1920, 30 fps, 450 кадров. Сам экспорт после сборки проекта занял около пяти секунд.

Все сцены, тексты и переходы лежат в исходниках. Можно хранить проект в Git, смотреть изменения и переиспользовать анимации для следующих роликов.

Причём самому писать Rust необязательно: говоришь агенту «кнопки пусть появляются по очереди», «телефон крупнее», «убери музыку» — он правит код и пересобирает видео. Но API настолько простой, что поправить что-то проблем вообще не составляет.

По пути узнал, что аналогичные видео Codex по-умолчанию создаёт на Python + Pillow, но это чуть менее эффективно.

Короче, такое монтирование видео мне очень и очень нравится.

🎞 Сайт
🐙 GitHub

Всё есть код, котаны.

#rust #fframes

О господи, да неужели я при жизни увижу стилизацию title?!!

Стилизация тултипов

Два года назад я писал о проблеме с title и о принятом рабочей группой CSS предложении добавить псевдо-элемент ::tooltip от Лии Веру. Похоже, команда Edge займётся тултипами, о чём можно судить по статье Патрика Броссета.

Дисклеймер: это обзор раннего предложения новых функций. Синтаксис может измениться в будущем или от функций могут отказаться

Общая практика такова, что стоит избегать использования атрибута title из-за ряда проблем. Патрик описывает эти проблемы в статье. Текущее решение команды Edge — добавить опциональный «сброс», как это сделано в стилизуемом <select>:

<style>
  /*
  Новый псевдо-элемент,
  выбирает все тултипы
  */
  ::tooltip {
    /* Включение стилизации */
    appearance: base;
    /* Стили тултипа */
  }
</style>
<button title="Это тултип">
  Наведи на меня
</button>

Свойство appearance: base включает стилизацию. Системный тултип заменяется на псевдо-элемент с базовыми стилями. Он привязан к элементу с помощью Anchor Positioning и работает под капотом на основе Popover API и Interest Invokers.

Это решает многие проблемы с тултипом title:

- Появляется при наведении и фокусе;
- Стилизуется как обычный псевдо-элемент;
- Задержка появления контролируется свойством interest-delay;
- Реагирует на изменение размера шрифта;
- Закрывается при нажатии Esc;
- Можно навести курсор на контент.

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

В качестве альтернативы предлагается новый атрибут tooltip. Он работает как title, но без отображения системного тултипа, с определённой семантикой и связями и ограничен <button>, <a>, <input>, <textarea>, <select>:

<style>
  ::tooltip {
    /* Стили тултипа */
  }
</style>
<button tooltip="Это тултип">
  Наведи на меня
</button>

С точки зрения доступности рекомендации для стилизуемых тултипов выглядят так:
- Не переопределяют имя элемента;
- Встроенная роль tooltip;
- Элемент ссылается на тултип через aria-describedby.

Но есть и другой способ создания тултипов — сочетание уже существующих Popover API и Interest Invokers. Вместо атрибута можно использовать элемент, связать его с триггером через Anchor Positioning и добавить поведение через атрибуты:

<!--
interestfor связывает кнопку
с тултипом и отображает
при наведении и фокусе
-->
<button
  interestfor="my-tooltip"
  aria-describedby="my-tooltip"
>
  Наведи на меня, у меня есть тултип с HTML
</TMLbutton>
<!--
popover делает элемент
всплывающим и позволяет
добавить любой контент
-->
<div
  id="my-tooltip"
  popover
  role="tooltip"
>
  Это тултип с <span>HTML</span>
</div>

В свежем 547 выпуске Веб-стандартов обсуждалась статья Патрика. Ведущие задались вопросом: зачем нам два разных способа создания тултипов, когда Popover и Interest Invokers решают задачу? Я вижу это как решения разных задач.

Простые задачи должны решаться просто. Атрибут title/tooltip и псевдо-элемент ::tooltip как раз для простых задач, где нужно вывести короткий текст или подпись к элементу. Браузер сам сделает магию связывания и доступности.

В более сложных сценариях, когда нужны тултипы с HTML или тонкий контроль, в дело вступают Interest Invokers. Но с ними нужно больше повозиться, чтобы сделать хорошо. Часть магии браузера не будет автоматически применяться.

Поэтому нужно вручную:

- Добавить отдельный элемент с popover, id и role;
- Позиционировать тултип относительно триггера через Anchor Positioning;
- Добавить триггеру interestfor и aria-describedby;
- Стилизовать тултип.

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

Можно оставить обратную связь по предложению Edge.

#html #css #ui

#ссылка дня

Недавно в нашем чате был жаркий спор на тему доступности. Мол, нормально делай — нормально будет и вообще морочить себе голову не надо, таких людей единицы.

Оно как бы и да и нет. Например, давайте представим себе на минуту средних дизайнеров сайтов и приложений.

Чаще всего они сидят в условиях, близких к идеальным. На стуле, перед большим монитором. И рисуют, не знаю, приложение для оплаты парковки. Он или она молоды и здоровы, мышка твёрдо лежит в руке. Идиллия.

Как по их представлению человек будет пользоваться приложением? Припарковался, устроился поудобнее и оплатил?

Да хрен там плавал. На бегу к офису, с документами в свободной руке. В этот момент здоровый человек превращается в инвалида, который в кнопку-то с трудом попадает. Телефон скользит, экран бликует. Это уж точно не идеальные условия.

И так с любым проектом. Думать надо.

Собственно, вот и ссылка на сегодня: https://a11ymyths.com/ru/

Мифы о доступности на разных языках. Всем читать, котаны.

#a11y #бородач

#инструмент дня

TanStack Charts 1.0 — Таннер Линсли довёл до стабильного релиза свою библиотеку графиков.

Вот это, конечно, эффективность у человека.

Анонс: https://tanstack.com/blog/tanstack-charts-1-0
Каталог: https://tanstack.com/charts/catalog

Charts устроен не как коллекция <LineChart>, <BarChart> и <PieChart>. График собирается из меток (marks), шкал (scales), осей (axes) и взаимодействий (interactions): можно начать с линии, добавить поверх точки, снизу столбцы, свои аннотации или вообще собственную метку (mark) — без поиска нового компонента под каждую комбинацию.

По умолчанию используется SVG, но тяжёлый слой можно отдельно перевести на Canvas, оставив оси, подписи и интерактивность в SVG. Canvas, анимации и более тяжёлые части не попадают в bundle, пока они действительно не понадобились.

Линсли пришёл к этой архитектуре после D3, работы над Chart.js 2.0 и собственного react-charts. Последний тоже со временем упёрся в ограничения заранее заданных видов графиков. Поэтому Charts построен ближе к Grammar of Graphics: визуализация складывается из отдельных частей, а не выбирается целиком из списка готовых типов.

Линсли пишет, что идеи для API копил около десяти лет, архитектуру и поведение проектировал сам, а почти всю реализацию отдал coding agents. Для Charts уже есть отдельный гайд по AI authoring — как агенту выбирать примитивы, проверять результат и не выдумывать несуществующие API. Собственный Skill через TanStack Intent тоже запланирован, но пока не выпущен.

В результате Charts рассчитан даже не столько на графики, это весьма решённая проблема, сколько на все придури вашего дизайнера :)

#charts #tanstack

#дичь дня

Лукас Бономи сделал GSS (GPU Style Sheets) — язык, на котором можно создавать полноценную 3D-графику, используя практически обычный CSS. И чем дальше читаешь документацию, тем больше вопросов к автору.

Объекты объявляются через @scene. Хотите куб? Пишите cube. Сферу? sphere. Трёхмерный бублик? torus. Можно назначить им классы и идентификаторы, расположить в пространстве и стилизовать привычными селекторами.

@scene {
  sphere#ball;
}

#ball {
  translate: 0 1 0;
  color: #ff5a36;
  material: glass(1.5, frosted 0.3);
  animation: float 2s ease-in-out alternate;
}

@keyframes float {
  from {
    translate: 0 1 0;
  }
  to {
    translate: 0 1.5 0;
  }
}

А дальше начинается прекрасное. Тут есть каскад, специфичность, `!important`, `:nth-child()`, `:hover` и даже `:has()`. Последний позволяет, например, менять внешний вид куба при наведении на соседнюю сферу. Да, теперь можно три часа выяснять, почему CSS не красит бублик.

Материалы тоже описываются стилями: metal(), glass(), jelly(), iridescent(). Есть градиенты, текстуры, освещение, тени, туман и фильтры. Анимации задаются через @keyframes, работают переходы и управление сценой через прокрутку страницы.

Причём это не какая-то хитрая обёртка над Three.js. GSS компилирует сцену в GPU-шейдеры GLSL или WGSL, а геометрия строится через SDF (функции расстояния) и raymarching. Никаких привычных полигональных мешей — видеокарта сама вычисляет поверхности объектов при отрисовке.

У проекта есть интерактивная песочница, npm-пакет, интеграция с Vite и даже расширение для VS Code. Всё это пока экспериментальное, но вполне работающее.

Не знаю, кому пришло в голову, что трёхмерной графике не хватает CSS-каскада и проблем со специфичностью, но теперь я хочу увидеть, как кто-нибудь будет отлаживать сцену с сотней объектов и !important.

https://www.gss-lang.dev/

#3d #webgpu

#статья дня

У vlt.io есть собственный коммерческий реестр npm-пакетов. Казалось бы, зачем кому-то альтернатива бесплатному npmjs.org? Но разработчики vlt решили покопаться в том, как npm передаёт метаданные пакетов, и нашли довольно много лишнего.

Например, полный документ с метаданными 759 версий Vite занимает 4,41 МБ даже после gzip. У npm есть сокращённый формат, но в нём не хватает некоторых полей, поэтому пакетным менеджерам иногда приходится запрашивать полную версию со всей накопившейся за годы историей.

В vlt переработали формат, убрали ненужные данные и сократили тот же документ Vite до 104 КБ. В среднем объём передаваемых метаданных уменьшился на 70%, а холодная установка зависимостей в их тестах ускорилась на 20–70%.

Причём менять пакетный менеджер не требуется: обычные npm, pnpm и Bun могут работать с альтернативным реестром. То есть значительную часть оптимизаций удалось сделать исключительно на стороне сервера.

Конечно, тесты проводились без lockfile, а в проектах с кешированием выигрыш будет скромнее. Но сама история показательна: спустя столько лет развития npm в его протоколе всё ещё остаются неэффективности, которые можно устранить, даже не меняя клиентский код.

https://www.vlt.io/blog/registry-metadata-70-percent-smaller

#npm #pnpm

#инструмент дня

Когда надоело, что ссылки из рабочего Slack открываются в личном профиле Chrome, а мемчики из Telegram — в рабочем.

Встречайте — ContextRoute! Создано мной с любовью для вас, котаны. Пока только для macOS.

Работает просто: выбираете, в каком браузере или профиле открывать ссылки из конкретных приложений.

Например, всё из Slack отправляется в рабочий профиль Chrome, из Telegram — в личный, а из остальных приложений — как принятно в macOS aka в последнее окно. Чуть меньше раздражения.

Альтернативы, конечно, существуют. Но мне они как-то не зашли.

Такие утилиты, во-первых, очень opinionated, а во-вторых, любят обрастать настройками. А я люблю минимум.

Вот, например, Yojam. У него только тёмная тема. И не просто тёмная, а чёрная! В сочетании с обилием, несомненно, прекрасных настроек пользоваться этим мне показалось невозможным. Skill issue.

Finicky — прекрасный инструмент, но зачем мне писать конфиг на TypeScript, чтобы открывать ссылки в браузере? Я вот не понял.

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

Надеюсь, что смогу вовремя остановиться. Хотя, наверное, разработчик Yojam тоже так считал.

#swift #macos

🏁Тестовый собес на Frontend с разработчиком из R-Vision, ex-Сбер

15 октября в 19:00 (МСК) приходи посмотреть открытое онлайн-собеседование на Frontend-разработчика!

Интервьюер: Даниил Дмитриев – Frontend-разработчик в R-Vision, ex-Сбер. Пишет на React и TypeScript, совмещает роль тимлида, менторит разработчиков и проводит код-ревью.

На эфире нет сценария ↓
Кандидат – случайный разработчик, который не знает вопросов заранее.

На обычном собесе ты не знаешь, что думает интервьюер, пока не придёт фидбек. На этом эфире Даниил проговорит всё вслух:

— какие вопросы и задачи даёт кандидатам на Frontend-собесах;
— что в каждом ответе засчитал бы, а что нет — и почему.

А в конце ответит на твои вопросы.

Эфир проходит в рамках менторской программы от ШОРТКАТ для разработчиков, которые хотят повысить грейд, ЗП и прокачать скиллы!

Участие бесплатное 🔥

Зарегаться на эфир можно в боте → @shortcut_front_bot

Реклама.
О рекламодателе.

#такое дня

Сидим, разрабатываем дизайн систему, следуем WCAG, вычитываем эксплейнеры с https://open-ui.org/, следуем всем законам о доступности...

Но мы все лишь грязь под ногтями дизайнеров Apple, потому что спроектировать убегающий из под курсора компонент в их понимании абсолютно нормально.

Что дозволено Юпитеру, не дозволено быку, да?

#apple #ui