«Эффективность не работает»

Видео выходного дня. Илья Якямсев честно и искренне рассказывает, почему всем в айти стоит думать о своём ментальном здоровье, как жить и что делать с рабочей депрессией, зачем думать о себе. Сложный, но жизнеутверждающий доклад, который за 5 лет не потерял в актуальности.

Осторожно, в видео есть мат, не включайте на всю громкость при детях :)

https://youtu.be/K6oZuB8_dU8?si=LvlbR22Jveyav5xI

Приведение численных типов в CSS

Наверняка вы сталкивались с тем, что в CSS нельзя делить, умножать, складывать и вычитать разные единицы измерения. То есть запись calc(100vw / 1px) не работает. А ведь так можно было бы получить количество пикселей в ширине вьюпорта, что можно было бы использовать для каких-нибудь интересных анимаций или других эффектов. Не ширину вьюпорта, а именно число пикселей, без единиц измерения.

Джейн Ори хакнула современные возможности CSS и всё-таки получила ширину вьюпорта числом.

1. Регистрируем CSS-переменную с типом <length>. Так браузер позволит использовать её в операциях с длиной, что пригодится нам дальше.

@property --100vw {
  syntax: "<length>";
  initial-value: 0px;
  inherits: false;
}

2. Используем обратные тригонометрические функции в CSS, а именно тангенс и арктангенс:

--width: calc(
  tan(atan2(var(--100vw), 1px))
);

Из школьного курса геометрии можно вспомнить, как работают тангенс и арктангенс. По сути здесь записано --100vw / 1px, зачем-то обёрнутое в вычисления. Но именно благодаря вычислениям в итоге внутри --width будет лежать число, а именно 100vw в пикселях. Если записать просто calc(var(--100vw) / 1px), вы получите ошибку.

В комментариях к статье Темани Афиф справедливо пишет, что сейчас в Chrome не учитывается тип делителя, что по сути является ошибкой браузерной реализации. То есть напишите там хоть 1px, хоть 1em, разницы нет. Но в будущем, когда тригонометрические функции починят, код с пикселями будет всё равно работать.

https://dev.to/janeori/css-type-casting-to-numeric-tanatan2-scalars-582j

Чеклист для дизайн-систем

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

Арда Карачизмели, Дмитрий Беляев и Стивен Багали собрали огромный чеклист, разбитый на 4 категории: дизайн-язык, основы, компоненты, поддержка. В блоке про компоненты по мне так супер-ценные напоминания, что нужно предусмотреть.

Если считаете, что чеклист неполный, можно законтрибьютить на гитхабе.

https://www.designsystemchecklist.com/

Вертикальное выравнивание через cap-height

Задача: выровнять иконку или картинку по центру относительно строки текста.

Кажется, всё просто: добавляем vertical-align: middle, коммитим, пушим, деплоим, профит. Но есть нюанс.

Дело в том, что vertical-align: middle выравнивает элемент относительно высоты строчной буквы x. Это так называемая x-height. И если текст у вас состоит только из строчных букв, то задача как будто решена, иконка действительно будет выровнена относительно текста. Но сомневаюсь, что у вас именно такой текст.

Рома Комаров показывает, как можно починить выравнивание для текстов с прописными буквами. В CSS не так давно появилась единица измерения cap, от английского capital — прописная. Это высота прописной буквы шрифта, cap-height. Прелесть в том, что браузер может сам высчитать эту высоту для шрифта, потому что он очень неплохо справляется с рендерингом текста. А это значит, что мы можем комбинировать x-height и cap-height, чтобы посчитать, какой отрицательный margin добавить иконке сверху: margin-top: calc(1ex - 1cap). В таком случае текст будет выровнен красиво по центру иконки или картинки.

Единица измерения cap появилась в Chrome 117, Safari 17.2 и Firefox 97. То есть пока ещё не самая высокая браузерная поддержка (чуть ниже 70% по данным caniuse на момент публикации поста). Для старых браузеров Рома предлагает фолбек на CSS-переменных, если у вас есть возможность достать параметры шрифта из самого шрифта. Пример кода — в статье. Ссылка на инструмент для извлечения метрик шрифта — тоже.

Когда вам в очередной раз зададут вопрос про вертикальное выравнивание блоков по центру при помощи CSS, сможете сделать ваш ответ ещё интереснее.

https://blog.kizu.dev/cap-height-align/

Идеального вьюпорта не существует

В Set Studio провели замеры на своих проектах, какого размера вьюпорт у пользователей. Собрали 120000 window.innerWidth и window.innerHeight. И оказалось, что уникальных размеров — 2300. Уникальный — это когда отличается или ширина, или высота, или оба измерения.

А теперь вспомните, сколько размеров у вас в условной Figma для ваших макетов, которые нужно сверстать. Хорошо, если 3: мобильный, планшетный, десктопный. Но чаще я видел всего 2 размера: совсем мелкий мобильный под какой-нибудь iPhone и большой для десктопов. Кстати, даже на том же iPhone есть как минимум 6 вьюпортов: Safari, WebView, превью сайта по долгому нажатию (бывший 3D Touch) и всё это при горизонтальном расположении экрана.

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

Кстати, на сайте можно найти полные данные про все 2300 уникальных вьюпорта, которые намайнили в Set Studio, если вам интересна более подробная статистика. Например, можно отранжировать по ширинам, чтобы понять, стоит ли тратить время на совсем уж мелкие экраны. Только не попадитесь в ловушку, перепутав причину и следствие: возможно, на ваш сайт не заходят с мелкими экранами, потому что он на них банально разваливается.

https://viewports.fyi/

Использование abbr с атрибутом noscript

В HTML можно пояснять аббревиатуры при помощи такого кода: <abbr noscript="National Aeronautics and Space Administration">NASA</abbr>. На странице покажется текст из содержимого тега abbr, а если навести на него мышку, то появится тултип с содержимым из атрибута noscript. Удобно же, правда?

Опустим тот факт, что системный тултип — ужасное решение, даже если он работает. Адриан Розелли проверил, как ведёт себя такая конструкция в разных браузерах и в разных операционных системах с точки зрения доступности с клавиатуры, на тач-устройствах, в голосовых ассистентах. И если коротко, то плохо. Подробности по ссылке.

Мораль: не используйте abbr. Чтобы он по-настоящему работал, всё равно придётся реализовывать собственную обёртку. А ещё лучше расшифровать аббревиатуру прямо в тексте. В книгах и журналах так делают сотни лет — и ничего, как-то люди эти тексты без курсора понимают. Если можно сделать текст понятнее без дополнительных действий — стоит это сделать.

https://adrianroselli.com/2024/01/using-abbr-element-with-noscript-attribute.html

Альтернатива live-server

Мне часто нужно запустить какую-нибудь html-страничку на мини-сервере, чтобы и айфреймы в ней работали нормально, и по локальной сети пошарить (с телефона открыть). И обычно я для этого использую npm-пакет live-server. Запускаешь npx live-server, ждёшь минуту скачивания зависимостей, профит. Или ставишь глобально, чтобы ждать минуту всего один раз.

Недавно увидел тред в твиттере, где искали альтернативу. И оказалось, ждать целую минуту не обязательно. Есть неплохой пакет servor, который умеет почти то же самое, npx servor работает почти мгновенно, для моих задач подходит полностью.

Оба пакета, если что, давно не обновляются на github, но это не делает их устаревшими: свою работу выполняют отлично.

https://github.com/lukejacksonn/servor
https://github.com/tapio/live-server

CSS First. Когда JavaScript не нужен

Осенью на HolyJS читал доклад про то, что умеет современный CSS (и не только) и какие библиотеки на JS, которые мы скорее используем по привычке, чем осознанно, можно уже сейчас заменить на CSS. Делал упор на том, как доставлять меньше байтиков на клиент, но в конце задвинул философскую мысль.

Теперь можно посмотреть доклад на YouTube, не сдерживайте себя.

https://www.youtube.com/watch?v=G_GwPX6hM9M

Стриминг HTML почти в любом порядке

Долго думал, чем мне может быть полезен декларативный Shadow DOM. Это такая конструкция, которая позволяет внутри template указать какой-то html, добавить этому шаблону атрибут shadowrootmode, всё это вместе со слотами. Вот пример кода:

<host-element>
  <template shadowrootmode="open">
    <slot></slot>
  </template>
  <h2>Light content</h2>
</host-element>

В примере контент из h2 передвинется внутрь слота, а само содержимое template окажется внутри Shadow Root элемента host-element.

Выглядит интересно, но я всё не понимал, как мне это дружить с фреймворками, которые уже есть в проектах. Фреймворки давно умеют в шаблоны, слоты сложнее в восприятии, чем JSX, да и внутрь Shadow Root прокинуть стили надо по-особенному.

Важная часть: Declarative Shadow DOM не нуждается в JavaScript. И в статье Крис Хейнс показывает, как это использовать.

1. Вам нужен сервер, который умеет стримить HTML. Таких много на любых языках. Стримить — это отдавать по частям, пропушивая на клиент некоторые кусочки, когда они уже готовы.

2. Для удобства Крис предлагает использовать шаблонизаторы, которые умеют в стриминг. Хотя на самом деле это совсем не обязательно, главное не ошибиться в том, когда какой кусок страницы отдаётся.

3. Сразу отдаём head со всеми метаданными, ссылками на стили и ресурсы, которые очень нужны для корректной работы страницы, чтобы браузер уже начал их выкачивать, пока вы готовите остальное.

4. Тут же отдаём template с пустыми именованными слотами. В этот момент браузер поймёт, что ему нужно будет в слоты что-то вставить, как только они приедут в разметке.

5. Крутим-вертим бизнес-логику, медленно ходим в БД, наполняем слоты данными. Как только данные готовы — отдаём содержимое с указанием, в какой слот его нужно вставить, в HTML-потоке.

6. Отправляем остатки HTML, закрываем теги, досылаем маловажные скрипты.

Самая магия происходит в пунктах 4 и 5. Шаблон страницы мы отдаём сразу, а вот его содержимое — позже. То есть вообще не соблюдаем порядок внутри HTML. Но отрендерится страница в том порядке, в котором вам надо. И всё это без JS на клиенте, он не нужен.

Подобный подход используют многие крупные сервисы: отдают сразу шапку и кусок универсальных стилей, а потом доставляют всё остальное. И этим сервисам приходится сталкиваться с ограничением порядка доставки. Тот же Яндекс.Поиск работает аж в три этапа: шапка, вехний важный результат выдачи, всё остальное. Интересно посмотреть, поможет ли Declarative Shadow DOM здесь и в скорости доставки контента не потерять, и в удобстве разработки не ухудшиться.

Работает DSD в Chrome и Safari, в Firefox довезут в конце февраля, есть полифил.

https://lamplightdev.com/blog/2024/01/10/streaming-html-out-of-order-without-javanoscript/

Подсветка текста в момент подскрола к нему

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

Крис Койер нашёл пример решения задачи на GSAP и переделал его на CSS Scroll-Driven Animation.

1. Создаём простую анимацию заполнения фона фразы при помощи изменения background-size от 0 до 100%. Залить можно градиентом. Или, например, можно сделать эффект подчёркивания текста, суть та же. Саму фразу выделяем каким-нибудь тегом вроде mark.

2. Добавляем animation-timeline: view();. Этим мы говорим браузеру, чтобы он вместо временной оси использовал позицию скролла. Причём по умолчанию привязываем 0% к появлению элемента во вьюпорте, 100% — к исчезновению из него.

3. Уточняем границы внутри вьюпорта, которые являются 0% и 100% для анимации: animation-range: contain 0% contain 25%;. Теперь заканчиваться анимация будет уже на 25% движения внутри вьюпорта.

4. animation-iteration-count: 1; — вызываем эффект всего один раз.

Работать будет только в Chrome и хромоподобных браузерах, но для других браузеров можно подключить тот самый GSAP-плагин, который упоминается в статье. И хотя бы в Chrome будет значительная экономия трафика.

https://frontendmasters.com/blog/highlight-text-when-a-user-scrolls-down-to-that-piece-of-text/

Автоматическая генерация постов со ссылками

Софи Кунин поделилась инструкцией, как автоматизировать публикацию постов с интересными ссылками у себя на сайте. У многих блогеров такое есть: они в течение недели собирают интересные ссылки на статьи и сайты, а потом выкладывают их со своими комментариями. А здесь всё сделано полуавтоматически.

1. Сами ссылки собираем в raindrop.io — это такой сервис, который позволяет упорядочить закладки.

2. У raindrop.io есть апишка, к которой довольно просто прикрутить токены доступа.

3. На GitHub в репозитории блога заводим новый workflow, который запускается по cron раз в неделю. Я себе установил каждую субботу в 11:30 UTC. Вся суть workflow в том, чтобы запустить наш кастомный генератор поста со ссылками и закоммитить сгенерированные файлы в репозиторий.

4. Запустить публикацию сайта в продакшен удобным способом. У меня Netlify, он автоматически подхватывает коммиты в main-ветку.

Генератор поста честно своровал у Софи, так как у меня тоже используется Eleventy с Markdown. И завелось всё довольно удачно, сегодня вышел пост со ссылками, сохранёнными в течение недели: https://mefody.dev/chunks/weekly-2024-01-27/.

Попутно увлёкся, сдул пыль с бложика, увеличил в нём шрифт, заменил старое лого и фавиконку (я на них с короткими волосами ещё), подкрасил ссылки, обновил Open Graph.

В общем, если вам интересно получать раз в неделю список ссылок на англоязычные статьи, которые я считаю интересными, то подписывайтесь на что-нибудь из:
- RSS
- Twitter
- Mastodon

https://localghost.dev/blog/automated-weekly-links-posts-with-raindrop-io-and-eleventy/

Стилизация скроллбаров

В Chrome 121 завезли поддержку свойств scrollbar-width и scrollbar-color. Там и раньше было наследие WebKit с префиксами, но теперь будет работать по стандарту.

Свойство scrollbar-width принимает три значения:
- none — прячет скроллбар, но оставляет возможность скроллить;
- auto — дефолтный системный скроллбар;
- thin — скроллбар потоньше.

Ширину в пикселях задавать нельзя, так решили при доработке стандарта. Что для пользователя, наверное, лучше: есть привычный элемент UI, который узнаётся по форме и размеру, на каждом сайте.

Свойство scrollbar-color принимает два цвета. В примере scrollbar-color: yellow green сам скроллбар будет жёлтый, а трек под ним — зелёный.

Брамус делится примером, как добавить совместимость со старыми браузерами и WebKit. В Firefox всё работает с 2018 года. Кстати, для Safari нужен костыль, если вы меняете цвет скроллбара на лету.

https://developer.chrome.com/docs/css-ui/scrollbar-styling

Отдельная фавиконка для локального билда

Когда чиню баги вёрстки, у меня обычно открыта страничка в продакшене, локальная версия и версия с тестового стенда для PR с правками. И несколько раз уже было, что почему-то правки не применяются, а потом оказывается, что смотрел не локальную версию, а прод.

Чтобы так больше не страдать, стараюсь прикручивать разные фавиконки к разным билдам проектов. Причём для локальной версии использую простейшую noscript-иконку с каким-нибудь эмодзи.

https://mefody.dev/chunks/favicon-dev/

git rerere

Как говорится, чем больше ты знаешь, тем меньше ты знаешь. Сегодня я узнал, что в git есть фича запоминать разрешённые при мердже или ребейзе конфликты.

Например, если вы работаете в какой-то «гигаветке» (долго делаете большую недробимую фичу), постоянно подливая из других веток изменения и разрешая одни и те же мерж-конфликты, то с включённой в конфиге опцией rerere (reuse recorded resolution) вы можете разрешить конфликт всего один раз, а затем git, если увидит, что в файле с таким-то именем уже была ситуация, что у нас такая-то строчка, а снаружи пришла такая-то строчка, то разработчик решал конфликт вот так. И, собственно, не будет спрашивать ещё раз, а решит, как вы решили в первый раз.

git config --global rerere.enabled true

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

https://git-scm.com/book/en/v2/Git-Tools-Rerere

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

https://news.1rj.ru/str/melikhov_dev/270

Пакет type-coverage

Я верю, что когда в TypeScript-коде есть any или костыльные приведения типов через unknown, то такой код может когда-нибудь выстрелить. Особенно если вы полагаетесь на типы как на один из слоёв его тестирования. Поэтому периодически в своих проектах прохожусь по any и вычищаю их.

Есть удобный пакет type-coverage, который ускоряет такую чистку. И его можно использовать по-разному:

1. Самый простой способ — запустить npx type-coverage в папке проекта, и он вам выдаст процент покрытия ts-файлов типами. Есть разные флаги, которые делают проверку строже, игнорируют try-catch, подсвечивают проблемные места в файлах и так далее.

2633 / 2670 98.61%
type-coverage success.

2. Для более удобной отладки можно прикрутить ещё один пакет, typenoscript-coverage-report. Он выводит отчёт в более удобном виде: табличкой в консоль и ещё более умной табличкой в HTML. Если ваш пайплайн CI/CD умеет работать с артефактами, этот отчёт можно прикрутить в описание пулл-реквеста, например.

3. Можно добавить в package.json минимально допустимое значение покрытия типами и настроить проверки на prepush-хуках, в PR и в релизах, например, чтобы нельзя было ухудшить покрытие. Знаю, в некоторых командах есть договорённости всё покрывать типами, и такая проверка экономит когнитивные усилия на код-ревью.

{
  "typeCoverage": {
    "atLeast": 99
  }
}

https://github.com/plantain-00/type-coverage

Interop 2024

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

Фокусные направления на 2024 год:
1. Доступность. В рамках Interop 2023 успели написать 1300 новых тестов, которые теперь надо научиться проходить.
2. CSS Nesting. Та самая нативная вложенность. Все браузеры уже её поддерживают, осталось дотюнить сложные моменты, например, для селектора :host.
3. Custom Properties. Сами кастомные свойства с нами давно, а вот @property — относительно свежая фича.
4. Declarative Shadow DOM. Веб-компоненты, не нуждающиеся в JavaScript.
5. Свойство `font-size-adjust`. Удобный способ выравнивать разные шрифты по высоте, даже если у них абсолютно разные шрифтовые метрики.
6. Поддержка HTTPS URLs в WebSocket. Раньше нужно было использовать протоколы wss: или ws:.
7. IndexedDB.
8. Layout. Флексы, гриды и сабгриды.
9. Pointer Events и Mouse Events.
10. Атрибут `popover`. Нативные кастомизируемые попапы.
11. Relative Color Syntax. Возможность превращать одни цвета в другие, незаменимая фича для цветовых палитр и темизации.
12. `requestVideoFrameCallback`. Для работы с элементом video.
13. Стилизация скроллбаров. scrollbar-width, scrollbar-color, scrollbar-gutter и отказ от префиксных версий.
14. `@starting-style` и `transition-behavior`. Полезные улучшения для анимаций.
15. Направление текста. Продолжение работы над лучшей поддержкой разных письменностей.
16. `text-wrap: balance`. Магия красивых заголовков одним свойством.
17. URL. Основа основ веба тоже развивается и требует соответствия стандартам.

Я не перестаю радоваться тому, как всё меньше приходится думать о кроссбраузерности. Браузеры решают эту проблему за меня.

Анонсы:
- WebKit: https://webkit.org/blog/14955/the-web-just-gets-better-with-interop/
- Mozilla: https://hacks.mozilla.org/2024/02/announcing-interop-2024/
- Google: https://web.dev/blog/interop-2024
- Edge: https://blogs.windows.com/msedgedev/2024/02/01/microsoft-edge-and-interop-2024/
- Igalia: https://www.igalia.com/2024/interop-2024-launches.html
- Bocoup: https://bocoup.com/blog/interop-2024

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

Видео выходного дня. Алексей Катаев делится рецептами упрощения жизни тимлида и команды.

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

https://youtu.be/ojRZNSSr4I8

<head>

Старенький, но всё ещё актуальный справочник по тому, что может быть внутри тега <head>. Подсматриваю в него периодически, чтобы не забыть какой-нибудь важный или интересный метатег. Например:

- <link rel="author" href="humans.txt"> — рассказать, кто разрабатывает сервис.
- <meta name="google" content="notranslate"> — попросить Google Translate не ломать смыслы (лучше, конечно, дать выбирать пользователю всё-таки, но иногда переводчик слишком плохо справляется со страницей).
- <link rel="webmention" href="https://example.com/webmention"> — подключить WebMentions.
- <meta name="twitter:dnt" content="on"> — попросить твиттер не следить за пользователями сайта (послушается ли он, другой вопрос, но попросить можно).
- <meta property="al:ios:app_store_id" content="12345"> — связать сайт и приложение в AppStore.

HTML Academy форкнула репозиторий отсюда, но оригинальный репозиторий покрыт пылью и не развивается много лет, поэтому всё же советую пользоваться форком.

https://github.com/htmlacademy/HEAD

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

Никита Прокопов рассказывает:
- что такое юникод;
- почему иконка 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