Frontend VK Hub

🔵 Chrome 156: IndexedDB на SQLite и random() в CSS 20 октября вышел Chrome 156. IndexedDB перевели с LevelDB и плоских файлов на SQLite без изменения API. В CSS появилась random(), а загрузку модуля после сетевого сбоя можно повторить через import(). В релиз вошли 353 исправления безопасности, шесть из них критические. 🔵 TypeScript 7.1 Beta: API компилятора и content mappers 20 октября вышла бета TypeScript 7.1 с API typescript/sync и typescript/async для разработчиков инструментов. Плагины content mappers позволяют подключать форматы вроде .vue и .svelte к проверке типов. Для запуска через tsc нужен --runExternalCode. В бенчмарке на mui-docs с --noEmit и четырьмя потоками проверка заняла 11,9 с против 22,2 с в TypeScript 7.0. 🔵 Chrome DevTools: Anchor Positioning и память замыканий 20 октября команда Chrome описала обновления DevTools для Chrome 155 и 156. В Elements появился визуальный редактор position-area, а Memory теперь находит неиспользуемые переменные, которые замыкания удерживают в памяти. Инструмент get_css_styles позволяет AI-агентам читать вычисленные стили и применённые CSS-правила. 🔵 Node.js: десять исправлений безопасности 21 октября вышли патчи 26.12.1, 24.22.1 и 22.23.4. В декодере Brotli закрыли уязвимость: распаковка вредоносных данных через node:zlib могла привести к повреждению памяти и удалённому выполнению кода. Проблема затрагивала все три ветки. 🔵 Safari 27.1: API для складного экрана за флагами 23 октября в Safari 27.1 на iPhone Duo появились экспериментальные Device Posture API и Viewport Segments API. Первый позволяет реагировать на частичный сгиб экрана, второй описывает области по обе стороны сгиба. Оба API доступны за флагами. 🔵 Safari 27.2: финальный релиз и правки Grid Lanes 26 октября вышел Safari 27.2. В кастомном <select> можно стилизовать отображаемое значение через ::field-content без <selectedcontent>. В Grid Lanes свойство flow-tolerance переименовали в fit-tolerance, старое имя временно работает как устаревший алиас. 🔵 Firefox 159: анимации по скроллу и реестры веб-компонентов 27 октября в Firefox 159 включили по умолчанию анимации, привязанные к скроллу. Появились scoped custom element registries: у shadow-дерева может быть свой реестр элементов. Одинаковые имена элементов из разных библиотек в таких реестрах не конфликтуют. 🔵 Next.js: запланирован security-релиз 27 октября команда Next.js анонсировала патчи для семи уязвимостей средней критичности. Релиз запланирован на 3 ноября, затронутые версии и инструкции по обновлению опубликуют вместе с исправлениями. 🔵 Node.js 26: LTS до апреля 2029 года 28 октября Node.js 26.13.0 перевёл ветку 26.x в LTS под именем Lithium. Поддержка продлится до конца апреля 2029 года. При переходе со старых LTS проверьте наличие libatomic в Linux-образах. Статьи от инженеров VK: ➡️ Прежде чем работать с AIDL: разбираемся, как устроен IDL ➡️ От AJAX до React: как мы полностью изменили архитектуру разработки фронтенда ВКонтакте #frontendvkhub #дайджест

overflow: auto clip в Chrome 156: липкая шапка таблицы в обёртке с горизонтальной прокруткой ➡️ Chrome 156 от 20 октября разрешил делать элемент контейнером прокрутки только по одной оси: элемент с overflow: auto clip прокручивается по горизонтали, а по вертикали обрезает содержимое. Раньше браузер заменял clip в паре с auto на hidden, и элемент становился контейнером прокрутки по обеим осям. Теперь getComputedStyle возвращает auto clip, а липкий элемент привязывается к контейнеру прокрутки отдельно по каждой оси. Базовый случай — таблица с липкой шапкой и липкой первой колонкой внутри обёртки с overflow-x: auto. У такой обёртки браузер заменяет overflow-y: visible на auto, и она становится контейнером прокрутки по обеим осям. Шапка с top: 0 липнет к обёртке и уезжает вместе со страницей, потому что по вертикали обёртка не прокручивается. В нашем тесте обёртка была шириной 400 px, таблица — 1 200 px, страница прокручена на 600 px. С overflow-x: auto шапка в Chrome 141, Chrome 156 и Firefox 158 уехала на 500 px за верхний край окна, а с auto clip в Chrome 156 осталась у края. .table-wrap { overflow-x: auto; } @supports named-feature(single-axis-scroll-container) { .table-wrap { overflow: auto clip; } } .table-wrap thead th { position: sticky; top: 0; } .table-wrap :is(th, td):first-child { position: sticky; left: 0; } Почему не @supports (overflow: auto clip)? Все актуальные браузеры принимают это значение, и CSS.supports возвращает true даже в Firefox 158, где поддержки нет. В блоге Chrome советуют named-feature(single-axis-scroll-container), и в нашем тесте это условие выполнилось только в Chrome 156. Без проверки браузеры без поддержки превратят auto clip в auto hidden, и всё, что выходит за нижний край обёртки, обрежется. У clip по второй оси есть побочные эффекты. По этой оси элемент не прокручивается и программно: после scrollTop = 150 свойство по-прежнему возвращает 0, а scrollIntoView прокручивает окно вместо обёртки. Выпадающий список, который выходит за нижний край, обрезается без возможности прокрутки, хотя scrollHeight обёртки показывает полную высоту, 380 px. Во flex-контейнере с flex-direction: column у элемента с overflow: auto clip начинает действовать min-height: auto, минимальная высота по содержимому. В нашем тесте в Chrome 156 такой элемент в контейнере высотой 200 px вырос до 600 px, а в Chrome 141 и Firefox 158 сохранил высоту 200 px. В Safari поддержки тоже нет, и там работает запасной overflow-x: auto. Сам auto clip ставим только на обёртку, которой нужна липкость по двум осям, и только внутри проверки named-feature. Выпадающие списки внутри такой обёртки выносим в верхний слой через popover и привязываем к кнопке через anchor positioning, а flex- и grid-элементам задаём min-height: 0, если clip стоит по вертикали, и min-width: 0, если по горизонтали. А как вы сейчас делаете липкую шапку у широких таблиц? #frontendvkhub #chrome #таблицы

Без текста

Без текста

Без текста

Без текста

Без текста

IndexedDB на SQLite в Chrome 156: транзакции, место на диске и тесты Chrome 156 от 20 октября начал переводить IndexedDB с LevelDB на SQLite. Web API не меняется, и в chromestatus переход отмечен как изменение, которого разработчик не увидит. Пока SQLite получают только сайты, для которых в профиле ещё нет хранилища IndexedDB, и только у пользователей из группы эксперимента. Перенос существующих баз запланирован на следующий этап. Разницу всё же видно. На LevelDB две readwrite-транзакции к разным хранилищам одной базы идут в Chromium параллельно, а на SQLite вторая ждёт, пока завершится первая. Спецификация это разрешает, и Firefox 158 в нашем тесте ведёт себя так же. ➡️ В карточках разбираем, кому уже включили SQLite, а также оцениваем транзакции, место на диске, скорость и надёжность записи.  #frontendvkhub #sqlite #chrome

Импорт текста через with { type: 'text' }: что делает браузер и почему в Vite он не работает 🤖 С Chrome 155 от 6 октября текстовый файл можно импортировать как модуль: import tpl from './card.html' with { type: 'text' }. Firefox поддерживает такой импорт с версии 153 от 21 июля, в Safari он есть начиная с Technology Preview 251, а в стабильной версии пока нет. Экспорт default содержит текст файла строкой, так что шаблоны, шейдеры и SVG можно подключать без fetch и без плагина сборщика. Браузер не проверяет MIME-тип ответа. В нашем тесте Chrome 156 и Firefox 158 вернули строкой и .js-файл, и ответы с text/html и application/octet-stream. Байты браузер всегда декодирует как UTF-8: кириллица из файла в cp1251 превращается в символы U+FFFD, а BOM в начале отбрасывается. Запрос уходит в режиме cors с Accept: text/plain,*/*;q=0.5 и Sec-Fetch-Dest: text, поэтому ответу с другого origin нужен заголовок Access-Control-Allow-Origin. Какую директиву CSP проверяет браузер? connect-src: при default-src 'none'; script-src 'self' импорт блокируется, а с добавленным connect-src 'self' проходит. Карта модулей различает записи по паре «URL и тип», поэтому файл, импортированный и как JS, и как текст, загружается дважды. Статический импорт в браузере без поддержки ломает весь модуль. Chromium 141 выдаёт TypeError: "text" is not a valid module type., и код модуля не выполняется. Пока Safari такой импорт не поддерживает, в коде без сборки оставляем динамический импорт с запасным fetch: async function importText(url) { try { return (await import(url, { with: { type: 'text' } })).default; } catch (e) { if (!(e instanceof TypeError)) throw e; const res = await fetch(url); if (!res.ok) throw new Error(`${res.status} ${url}`); return res.text(); } } Перехватываем только TypeError: эту ошибку import() выдаёт при неизвестном типе модуля. Сбой сети тоже даёт TypeError, и тогда fetch запрашивает файл повторно. URL передаём абсолютным, например new URL('./card.html', import.meta.url).href: import() отсчитывает относительный путь от URL модуля, а fetch — от URL документа. В Vite 8.3 атрибут не работает. Известные ему ассеты вроде .txt и .svg он молча превращает в URL: файл меньше 4 KiB становится data URL, остальные уходят в /assets/…. Шаблоны .html, .md и шейдеры Vite разбирает как JS, и сборка падает с MISSING_EXPORT или PARSE_ERROR. esbuild 0.28 и webpack 5.112 учитывают атрибут и встраивают содержимое строкой. TypeScript 7 без declare module '*.txt' выдаёт TS2307 (Cannot find module). В проектах со сборкой синтаксис можно писать уже сейчас, если сборщик его понимает, а для Vite нужен суффикс ?raw или плагин, который переписывает такие импорты на ?raw. Без сборки нативный импорт берём, только когда его поддерживают все целевые браузеры, а до тех пор подключаем файлы через importText. #frontendvkhub #chrome #vite

JPEG XL вернулся в Chrome: что с ним делать фронтенду У любого большого сервиса есть терабайты старых JPEG, которые никто не трогает. Пережимать их в AVIF жалко: каждое сжатие с потерями добавляет новые артефакты к старым, а оригинал потом не вернуть. Вот они и лежат, и каждый день уезжают к пользователям в исходном весе. JPEG XL умеет перепаковывать JPEG без потерь. Файл становится в среднем на 20% легче, а если понадобится, из него можно собрать исходный JPEG байт в байт: cjxl photo.jpg photo.jxl djxl photo.jxl restored.jpg Если на входе JPEG, cjxl перепаковывает его без потерь по умолчанию — флаги не нужны. Долго от этого было мало толку. Chrome перестал поддерживать  формат в 2023 году, в версии 110, а без самого популярного браузера возиться с JXL никто не хотел. 6 октября Chrome 155 включил JPEG XL обратно, на этот раз с декодером jxl-rs на Rust. 13 октября формат включил и Firefox 158, а Safari поддерживает JXL ещё с версии 17. Правда, «поддерживает» в случае Safari — громко сказано. Он показывает только статичные картинки, без анимации и прогрессивной отрисовки, поэтому большой hero появится целиком и только после полной загрузки. В Edge и Samsung Internet формата нет вовсе, так что без запасного варианта не обойтись: <picture>   <source srcset="/img/hero.jxl" type="image/jxl">   <source srcset="/img/hero.avif" type="image/avif">   <img src="/img/hero.jpg" width="1600" height="900" alt=""> </picture> Здесь важен порядок source. Если JXL стоит первым, Safari выберет его вместо AVIF и покажет hero только после полной загрузки. Для LCP-картинки такой порядок может оказаться хуже, чем AVIF на первом месте, так что оба порядка лучше замерить на реальных страницах, чем гадать. С анимацией решение проще: в JXL через <picture> её не отдаём совсем. Атрибут type не отличает анимацию от статики, поэтому Safari честно выберет файл, который не сможет проиграть. Отдавать формат по заголовку Accept тоже можно, но удовольствие сомнительное. Понадобится Vary: Accept, и кеш CDN раздробится. К тому же браузеры перечисляют форматы в разном порядке. Firefox, например, ставит image/jxl после image/avif, и сервер, который берёт первый тип из списка, разным браузерам отдаст разные форматы. Тем, кто обрабатывает картинки в Node, стоит знать ещё одну деталь: в готовых сборках sharp нет libjxl, а вывод в JXL там помечен как экспериментальный. Проще вызывать cjxl напрямую или переложить конвертацию на CDN. Начинать лучше с архива. Старые JPEG перепаковываем без потерь и отдаём через <picture> с JPEG в запасе: качество не страдает, трафик падает сразу. Для новых картинок JXL стоит сравнить с AVIF на своём контенте. Google и сам советует пробовать оба формата и отмечает, что JPEG XL полезнее всего при высоком качестве и при сжатии без потерь. А у вас старые JPEG так и лежат как есть? #frontendvkhub #jpeg #chrome