CLI для caniuse

Брамус собрал консольную утилиту, чтобы смотреть на данные caniuse прямо из терминала. Причём можно ещё и подключить автодополнение для bash/zsh/fish.

Поигрался — выглядит интересно. Если надо быстро посмотреть поддержку, без деталей, то экономит время. Но полноценной заменой caniuse, конечно, эта утилита не станет. Уж слишком я люблю с фильтрами разными на сайте играться. И не всегда помню правильное название CSS-фичи, ищу по ключевым словами, а утилита от Брамуса не всегда понимает, что я от неё хочу.

https://github.com/bramus/caniuse-cli

Состояние ES5 в вебе

Филип Уолтон ещё в 2017 году показал технику, которая позволяет для старых браузеров загружать отдельный транспилированный в ES5 код, а для современных — свежий модный ES6. В этом году он решил проверить, используют ли популярные библиотеки до сих пор ES5 как дефолт, когда как будто в этом уже нет нужды.

- Babel превращает строчку console.log([1, 2, 3].at(-1)) в 11217 байт кода, используя при этом 71 зависимость.
- Из популярных современных бандлеров только Babel и TypeScript используют транспиляцию в ES5 по умолчанию. Остальные сборщики всё-таки опираются на «современные браузеры».
- Популярные библиотеки тоже постепенно переходят на подход с современным синтаксисом в коде по умолчанию, без поставки ES5-версии. Хотя React и Lodash всё ещё содержат только ES5-код при подключении как зависимость.
- При этом Филип проанализировал топ популярных сайтов через HTTP Archive и обнаружил, что 89% сайтов подключают хотя бы один файл, где есть ES6+ фича без транспиляции. То есть в старых браузерах всё равно что-то сломается.
- То, во что превращается исходный код, должен решать пользователь, а не библиотека. Если мне зачем-то всё ещё нужно превращать мой код в ES5-бандл, я могу настроить сборку сам.
- На сборщик надейся, а сам тестируй. Какая бы сборка у вас ни была, собирайте клиентские ошибки, тестируйте приложения в популярных браузерах, не бойтесь автотестов с настроенными браузерными фермами.

https://philipwalton.com/articles/the-state-of-es5-on-the-web/

display: contents

Очередной подробный гайд от Ахмада Шадида по тому, как пользоваться некоторыми особенностями CSS. На этот раз про свойство display: contents.

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

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

Важно, display: contents может ломать доступность в списках, таблицах и прочих значимых для скринридеров элементах. Так что применяйте осторожно.

https://ishadeed.com/article/display-contents/

TypeScript 5.6

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

1. Проверки на nullish и truthy. Грубо говоря, в TS завезли аналог проверки no-constant-binary-expression из ESLint, хотя это не совсем так. Представьте, что вы где-то опечатались и внутри if написали код, который всегда true. Линтеры умеют такое подсвечивать, теперь умеет и TypeScript. За исключением явного задания if (true), потому что такое вы скорее всего пишете осознанно, например, для дебага или вебпака.

2. Методы Iterator Helper. В ECMAScript на 3-м уровне пропозала появились методы map, filter, reduce, take и другие для итераторов. TypeScript готовится к ним заранее. Не только поддержали новые методы, но и добавили новые встроенные типы IteratorObject и AsyncIteratorObject, которые позволят типизировать то, с чем работает итератор.

3. Строгая проверка итераторов `--strictBuiltinIteratorReturn`. Раньше было сложно определить, что вернёт итератор, поэтому по сути TS работал с типом any, а это убивает сам смысл типизации. В строгом режиме проверок теперь TS умеет определять типы умнее и начнёт выдавать полезные ошибки в случае неправильного использования результатов итераторов.

4. Поддержка Arbitrary Module Identifiers. В JavaScript можно сначала в модуле написать export { banana as "🍌" };, а потом в месте подключения модуля написать import { "🍌" as banana } from "./foo" — и это будет работать. Я не очень понимаю, для чего это нужно, кроме как для каких-то специфических способов именовать методы вроде MyLib::MyMethod, для совместимости по имени с бекендом, например. Но теперь в TS это поддержали, можно давать странные имена импортируемым сущностям.

5. Опция `--noUncheckedSideEffectImports`. Раньше TS мог игнорировать файлы, которые подключаются через import "some-module";, но не существуют. Такие подключения как раз называют импортами сайд-эффектов, потому что обычно оно нужно, чтобы выполнить какой-то код внутри модуля, но не импортировать ничего именованного. И так часто подключают CSS-файлы внутри компонентов. С включённой опцией TS теперь начнёт ругаться, если файл найти не может. Выключить конкретные маски можно, в статье есть пример.

6. Опция компилятора `--noCheck`. Убирает ненужные проверки типов для вывода новых файлов. По сути если у вас так настроен запуск tsc, что какие-то файлы с типами не нужны, то их и не будет проверять, экономя время. То есть если вы хотите просто быстро сгенерировать JS, не проверяя типы — осторожно, но можно.

7. `--build` без учёта ошибок зависимостей. Раньше если при билде TS находил ошибку типов в зависимостях, то падал и не давал сборке продолжаться. Теперь он постарается завершить сборку любой ценой, но начнёт всегда создавать файл .tsbuildinfo, куда будет писать информацию об ошибках. Чтобы вернуть старое поведение, нужно добавить в запуск опцию --stopOnBuildErrors.

8. Для быстрой работы в редакторах кода добавили языковому сервису TS возможность анализировать не весь файл целиком, а его видимые регионы. При редактировании огромных файлов сервису на каждый ввод символа нужно быстро реагировать, но это не всегда возможно, если анализировать весь файл сразу. По тестам над файлом checker.ts из самого TS время анализа первого региона из файла стало 143ms, а раньше полная диагностика файла занимала 3330ms.

9. Починили поведение `override`. Теперь проверки стали строже, требуют наличие перезаписываемого метода в базовом классе.

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-6/

State of HTML 2024

Ещё один опрос про состояние веба, на этот раз про HTML. Можете повлиять на то, какие новые возможности работы с элементами появятся в будущем. И заодно узнать про те, что уже есть — вопросы составлены таким образом, что можно чему-то научиться в процессе.

Набрал 340 баллов. Из 49 фичей, упомянутых в опросе, применял на практике 25, слышал о 18. Не зря в подкасте смотрим в релиз-ноуты браузеров, мало какая новинка прошла мимо.

https://survey.devographics.com/en-US/survey/state-of-html/2024

Текстовые альтернативы для эмодзи в скринридерах

Наткнулся на старую заметку Стива Фолкнера про то, как звучат в скринридерах эмодзи. Забавно, что одни и те же эмодзи где-то smiling (улыбающийся), где-то grinning (ухмыляющийся), а где-то beaming (сияющий). То есть визуально это одно и то же, но если интерфейс слушать — это разные смыслы.

Мораль: подбирайте эмодзи аккуратно, чтобы нечаянно не ухмыльнуться вместо доброй улыбки 🙂

https://html5accessibility.com/stuff/2022/01/17/short-note-on-emoji-text-alternative-variations/

ts-blank-space

Появляется всё больше способов собирать из TypeScript исполняемый JavaScript. Компания Bloomberg поделилась своим решением. Их компилятор ts-blank-space работает по принципу «заменить все лишние символы на пробелы». И это неплохо работает во многих случаях.

- По сути отстреливание типов — давно рабочий способ. Тот же Node.js научился недавно делать так же для TS-файлов, когда нужно запустить код.

- Замена всякого вспомогательного на пробелы — интересная идея, позволяющая избавиться от source map. Использование source map не бесплатное, при этом в случае ошибки всё ещё хочется посмотреть в исходный код. Позиции оригинальных символов при замене на пробелы не изменяются, профит.

- К сожалению, придётся отказаться от фичей TS, которые всё-таки влияют на рантайм: enum, namespace, module и парочки других.

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

- Подход настолько простой, что на их бенчмарке сборка быстрее tsc в 5.6 раз.

- Это опенсорс. Можете сами посмотреть, как оно под капотом устроено. И законтрибьютить, если захочется.

Попробовал у себя на двух проектах. На супер-простом серверном завелось всё без проблем. На большом проекте с легаси и tsx развалилось, конечно. Так что пробовать лучше на небольших проектах.

https://bloomberg.github.io/ts-blank-space/

Никита Дубко и Александра Шинкевич: Зачем разработчику выступать?

Видео выходного дня. Сходили с моим замечательным другом Сашей Шинкевич в гости в подкаст к Cloud.ru Tech. Делились мыслями про то, что такое личный бренд, стоит ли его развивать, для чего существуют конференции и нужно ли пробовать себя в роли спикера. Заодно про веб-технологии поговорили в общем и про «Веб-стандарты» как сообщество.

https://www.youtube.com/watch?v=0giBnxrTTGY

Улучшаем перфоманс рендеринга при помощи content-visibility

Нолан Лоусон делится интересным примером того, как одним осознанным применением полезного CSS-свойства можно принести много пользы.

Представьте, что у вас есть библиотека, которая помогает работать с тысячами различных картинок. У Нолана это веб-компонент emoji-picker-element, который как в Slack умеет в кастомные эмодзи. Если в такой компонент добавить 20000 эмодзи, то по сути это необходимость отрендерить не меньше 20000 DOM-элементов. Если же для каждого эмодзи нужно несколько DOM-элементов, простым умножением приходим в ужас.

Чтобы не писать свой виртуальный список, Нолан пошёл на следующие ухищрения:
1. Добавил для каждого списка эмодзи content-visibility: auto; и contain-intrinsic-size, который считался на основании количества эмодзи в списке. Такими командами вы разрешаете браузеру не рендерить контент, чтобы экономить время. Этим приёмом получилось ускориться уже на 15%.
2. Свёл количество DOM-элементов до минимального, то есть на один эмодзи — один элемент. Для этого саму картинку перенёс в background-image. Это не сломало a11y, так как оставшийся элемент всё ещё содержал всё необходимое.
3. Написал свой простой аналог loading=lazy для картинок на основе IntersectionObserver, чтобы избавиться от ненужных запросов за этими самыми картинками. В итоге получил общий прирост производительности от 35% в Firefox до 40% в Chrome.

Заодно из статьи я узнал, что существует ивент с именем contentvisibilityautostatechange. Это не кот по клавиатуре прогулялся, а специальный ивент для отслеживания изменения content-visibility: auto.

https://nolanlawson.com/2024/09/18/improving-rendering-performance-with-css-content-visibility/

Работа с буфером обмена при помощи JavaScript

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

Реймонд рассказывает про Clipboard API, как с его помощью читать HTML-код, как обрабатывать бинарные файлы (например, картинки) и что там с безопасностью вообще. Понравился пример, как можно скопировать в буфер обмена урл и сразу же записать в буфер QR-код с этим урлом.

Про чтение: https://frontendmasters.com/blog/reading-from-the-clipboard-in-javanoscript/
Про запись: https://frontendmasters.com/blog/writing-to-the-clipboard-in-javanoscript/

Нужен ли режим сепии по умолчанию?

Татьяна Фокина на примерах очень хорошо объясняет, почему тёмной и светлой тем недостаточно для комфортной работы с сайтом.

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

Многие операционные системы поддерживают похожий режим для всего интерфейса сразу, когда цвета становятся более тёплыми.

Астигматизм — очень распространённая особенность зрения у взрослых, поэтому, возможно, не помешает в браузерах добавить какую-то дополнительную настройку доступности. Но пока такого нет, есть смысл для заботы о пользователях добавить третью тему. Таня верно в статье замечает, что менеджеры такому «обрадуются», конечно. К тому же кому-то тёмная тема как раз более комфортна для зрения, чем режим сепии. Но задуматься о том, что доступность — это не только про контрастность, важно.

https://a11y-blog.dev/ru/articles/is-sepia-mode-essential/

Анимирование высоты при помощи CSS

Про эту новость в соц. сетях не написал только ленивый, кажется. Но я же не ленивый, поэтому тоже напишу.

В прошлом году у меня был доклад про то, как многие вещи, которые мы привыкли делать при помощи JS, на самом деле уже можно делать на чистом CSS. Но мне тогда задали очень правильный вопрос: «А без костылей плавную анимацию раскрытия details уже можно как-то сделать?» Я тогда что-то невнятное ответил, что есть черновики спецификаций, можно поиграться с max-height, то есть способы есть, но не все удобные.

Так вот, свершилось. В CSS теперь завезли свойство interpolate-size. И если вы зададите interpolate-size: allow-keywords, то тогда вы действительно можете анимировать из и в height: auto. Больше не нужно хаков с расчётом высоты на JS, подстановкой в атрибут style, потом после анимации не забыть убрать. Браузер в этот момент знает, что высоту надо посчитать, прямо до пикселей.

Да, пока это только браузеры на основе Chromium. Да, пока это можно использовать только как прогрессивное улучшение. С другой стороны, прогрессивное улучшение на половине ваших пользователей, когда раньше не было вообще ничего — это же классно. А ещё это новое свойство вместе с функцией calc-size() уже предлагают добавить в Interop 2025, на что я очень надеюсь.

https://gomakethings.com/animating-height-with-only-css/

Почему фронтендерам много платят

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

В «600к в секунду» ребята обсудили, действительно ли мы достойны получать свои зарплаты. Фронтендеры же просто формочки делают да кнопки двигают, за что там платить. Вот в этих ваших бекендах настоящее программирование, они там алгоритмы применяют, с базами данных общаются, огромные массивы данных обрабатывают…

В подкасте ребята хорошо прошлись по тому, как развивалась индустрия, почему фронтенд в 2024 году уже не просто формочки и кнопки, а полноценные приложения, да и фулстеков никто не отменял. Обсудили, почему сложность современного фронтенда такая высокая (тут хочется вставить мем с гусём «А кто фронтенд таким сложным сделал? Кто, я спрашиваю?»), хотя порог входа в профессию до сих пор достаточно низкий. И даже зацепили сложную тему «чем фронтенд-разработчик отличается от инженера».

В некоторые моменты хотелось ворваться в комменты под видео, написать «Да нет, не так всё, вы вообще неправильно всё обсуждаете!». Значит, эмоции зацепили, хорошее видео.

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

https://news.1rj.ru/str/itsmirnov/634

Бенчмарк производительности @​property

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

@property --color-primary {
    syntax: '<color>';
    inherits: true;
    initial-value: tomato;
}

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

1. Сравнение обычного наследуемого свойства, незарегистрированного кастомного свойства и зарегистрированного наследуемого кастомного свойства (`inherits: true`).
В целом, разница для кастомных свойств небольшая. Кастомные свойства в любом случае обрабатываются быстрее, чем обычное свойство. Но зарегистрированные свойства всё-таки чууууть-чуть медленнее.

2. Сравнение обычного ненаследуемого свойства и зарегистрированного ненаследуемого кастомного свойства (`inherits: false`).
Тут уже интереснее. Конечно, логично, что наследование замедляет инвалидацию. Но тут бенчмарк показывает прирост производительности на 1780% (прописью: тысяча семьсот восемьдесят) для обычных свойств! И 848% — для кастомных. При этом обычные свойства производительнее, чем кастомные.

3. Замер времени на обработку 25000 регистраций кастомных свойств.
Почти никак не влияет. Так как регистрация свойств происходит в самом начале загрузки приложения, то результат в 30ms на обработку 25000 регистраций — ничто по сравнению с загрузкой самого CSS, эти регистрации содержащего.

Выводы:
- Если есть возможность задать кастомному свойству inherits: false — задайте. Прирост производительности при наличии большого количества кастомных свойств будет колоссальный. А с современными дизайн-системами у вас скорее всего таких свойств много.
- Лучше зарегистрировать свойство, чем не зарегистрировать. Время на обработку таких конструкций мизерное, зато на выходе получаете полноценное свойство с понятным браузеру значением. Но тут надо внимательно следить за размером CSS-бандла, потому что он точно распухнет.

https://web.dev/blog/at-property-performance

Потратил целый день на оптимизацию производительности CSS-селекторов

Трис Мадфорд делится поучительной историей о том, как они с коллегой нашли во вкладке Performance в девтулзах галочку «Enable CSS selector stats (slow)» и увидели, что работа с селекторами занимает целых 270 мс.

Трис слышал, что в современном мире париться по поводу производительности селекторов вообще не стоит, поэтому его сильно смутило такое большое значение. Он переписал всякие непроизводительные селекторы на классы и атрибуты, запустил аудит ещё раз, увидел экономию в 230 мс, обрадовался. Затем проверил то же самое на WebPageTest — а там изначально было около 12 мс, а стало около 10 мс.

Выводы:
- Всегда проверяйте не лабораторные замеры, а RUM (Real user monitoring). Трису это позволило понять, что он потратил целый день почти впустую.
- Галочка «Enable CSS selector stats (slow)» реально замедляет сам процесс профилирования, поэтому её нельзя воспринимать как часть замеров общего перфоманса, слишком большое влияние. Надпись «slow» как будто должна была натолкнуть на правильные мысли, но я бы тоже ошибся, потому что обычно эта надпись говорит про то, что само профилирование будет идти дольше.
- С одной стороны перфоманс селекторов и правда почти никак не влияет на общий перфоманс страницы. Но если вы разрабатываете сервис, где каждая миллисекунда загрузки стоит больших денег бизнесу, то всё-таки 2 мс Трису удалось выиграть всего за день.

https://www.trysmudford.com/blog/i-spent-a-day-making-the-website-go-2ms-faster/

Доке — 3 года!

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

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

https://teletype.in/@doka_guide/MmnpSofIQSH

CSS @scope

Мириам Сюзанн объясняет, в чём разница между обычным сложным селектором и относительно новой директивой @scope в CSS. Напомню, в CSS теперь можно задать область применения CSS-правил относительно какого-то родителя. И если раньше мы это делали банальным перечислением классов, то сейчас есть другой способ.

- Специфичность псевдокласса :scope, который позволяет обратиться к тому самому ограничивающему элементу, всегда равна [0, 1, 0].
- При этом вложенные в @scope селекторы не увеличивают свою специфичность. Это позволяет решить ту проблему, которую долгое время помогал решать БЭМ — борьба со специфичностью в проекте.
- При помощи синтаксиса @scope (.from) to (.to) можно задать «бублик» применения стилей. То есть стили начнут применяться по дереву внутри .from, но не будут залазить внутрь .to. Это вполне себе полезно для различных сложных компонентов со слотовой структурой.
- Чем ближе @scope по DOM-дереву, тем значимее стиль. Ещё раз, при нескольких @scope на странице, применимых к одному блоку применится не тот, что ниже в CSS-файле, а тот, что ближе к элементу по DOM-дереву. Это принципиально другой подход к стилизации.
- <style>@scope {...}</style> — гига-фича, позволяющая привязать стили к родительскому над style элементу. Я таким образом демки для слайдов начал собирать, чтобы не париться с iframe. Никаким наследованием такое не сделать. Как CSS-модули, только нативное и без предобработки.

Жду, когда эта крутая фича станет доступна не только в Chromium, но для демок в докладах пока хватает.

https://12daysofweb.dev/2023/css-scope/

Введение в Shared Compression Dictionaries

Новый интересный способ сжатия поверх HTTP подъехал. Точнее, относительно новый и относительно подъехал, но обо всё по порядку.

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

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

Был ещё такой проект, SDCH (Shared Compression Dictionary over HTTP). К сожалению, его реализация была супер-небезопасной, из-за чего браузеры перестали его поддерживать.

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

А что было бы, если бы браузеру можно было сказать, чтобы он взял старую версию файла (из кэша, чтобы почти мгновенно), а потом поверх неё применил только дифф, как в git? И ещё сжал этот дифф, потому что он же тоже текст. Если максимально упростить и опустить море деталей, в этом и суть Delta Compression. Старую версию используем как словарь, а новая получается применением диффа.

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

Лабораторные тесты показывают, что новый формат может как ничего не давать полезного вообще (тот же Brotli вполне себе мощный из коробки), так и экономить до 80% трафика. Так что не стоит бросаться внедрять просто потому что, начать стоит с пробных замеров.

И как же этим пользоваться, если всё-таки готовы?

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

- Amazon CloudFront, Cloudflare и Fastly уже поддержали этот формат у себя. Думаю, другие CDN тоже скоро подтянутся, потому что это позволяет на том же железе зарабатывать в разы больше на раздаче статики. Золотая жила.

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

- Хоть и выглядит всё довольно сложно, верю, что автоматизацию в случае успеха в Chrome подвезут быстро. Когда-то нужно было `.gz`-версии файликов подкладывать руками рядом с обычными версиями, чтобы твой сайт работал быстрее, чем у конкурентов, а сейчас многие даже и не в курсе, что у них на сервере gzip-сжатие срабатывает автоматически.

https://www.debugbear.com/blog/shared-compression-dictionaries

Цвета в console.log()

Джим Нильсен дебажил в приложении цвета, которые меняются при помощи JS, и делал это самым правильным способом: через console.log(). Но беда в том, что если написать в консоль new color is hsl(62 50% 25%), это не то чтобы полезно. Не знаю как вы, но я не умею до сих пор быстро представлять в голове цвета по числам.

Джим вспомнил, что ещё в 2018 году у него была заметка в блоге про то, как стилизовать вывод console.log(). На самом деле если написать console.log('%c some text', 'color: white; background-color: black'), то %c и будет указанием браузеру применить стили из второго аргумента при выводе в консоль.

Я про такой лайфхак хоть и знаю давно, всё никак не мог найти полезного применения. А ведь для дебага цветов это самое оно.

https://blog.jim-nielsen.com/2024/color-console-log/

Уроки, полученные от 222 557 шрифтовых сабсетов

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

Он взял 1009 шрифтов из гитхаба Google Fonts, при помощи fontkit исследовал, какие глифы есть в каждом из шрифтов, затем, используя Glyphhanger, сгенерировал 222 557 отдельных файлов шрифтов, чтобы в них было от 1 до N глифов. Заморочился, конечно, знатно, но зато в статье можно найти примеры скриптов, как можно так же заморочиться.

В итоге Стоян опытным путём выяснил, что каждый глиф в среднем весит 0.1 KB, то есть если вы используете какой-то шрифт только для заголовков на статическом сайте, то есть смысл оставить только нужные символы. И если у вас нет кириллицы на сайте в принципе, то её имеет смысл вынести в отдельный сабсет.

Почему не убрать целый набор символов совсем? Потому что есть браузерный автоперевод, когда текстовый контент всё равно меняется на те символы, которые вы не предусмотрели. И если вы хотите, чтобы было красиво, то лучше оставить возможность докачать шрифт. Но чтобы не грузить всё сразу, unicode-range вам в помощь — браузер скачает только то, что есть на странице в виде символов.

https://www.phpied.com/lessons-learned-from-222557-font-file-subsets/

Адаптивный TOC с точками-соединителями для страниц на CSS

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

Для веба такой пример скорее бесполезен, потому что нет такого понятия, как страница. Но если вы верстаете что-то типографическое (а многие книги, на самом деле, вполне себе верстаются в веб-инструментах), то есть прекрасная спека с content: leader(dotted); — делает ровно то, что надо. Беда в том, что работает это примерно нигде. Мне в далёком 2017 году пришлось подключать PrinceXML, который умеет в печатные стили лучше браузеров.

Кристоф Грабо попробовал использовать для такого гриды и хак с переполнением контента. Получилось вполне себе адаптивно. Причём он использует точки как текст, разделяет их пробелами. Из-за этого лишние точки переносятся на следующую строку, не оставляя артефактов. Взял себе на вооружение, если вдруг снова понадобится верстать что-то печатное.

https://markentier.tech/posts/2021/03/responsive-toc-leader-lines-with-css/