Отслеживание поддержки фич

18.01.2026 • js, css, html, dom

Вступление

Браузеры развиваются семимильными шагами. Если 5-10 лет назад было тяжело отследить выход новых возможностей в браузерах и знать их все, то сейчас и подавно. А уж для нового разработчика знать, когда что вышло, вообще почти невозможно.

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

Информация о поддержке

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

MDN

Самый крутой сайт с документацией о веб-разработке. И уже очень давно.

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

Также в табличке можно встретить и поддержку в Node.js, Deno и других окружений.

MDN

Can I use

Ещё один очень известный сайт про поддержку разных фич. Частично переиспользует те же данные, что и MDN, частично основан на своих данных (поэтому некоторые фичи дублируются).

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

Can I use

Can I email

Очевидный кивок в сторону Can I use, но с другим уклоном. Я очень не завидую людям, которые верстают электронные письма, ведь браузеры договариваются и регулярно обновляются. А вот с почтой всё сложнее. Тут и обилие клиентов, и абсолютно разные движки, и крайне малое количество попыток синхронизации и модернизации среди разработчиков этих программ.

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

Как итог — банальный flexbox всё ещё нельзя с уверенностью использовать в письмах.

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

Так что приходится быть начеку.

Can I email

Accessibility Support

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

Работает ли определённое значение role? Или, например, атрибут inert? С этим может помочь тестирование, но могут и сайты по типу Accessibility Support.

В отличии от своих предыдущих собратьев, предоставляют не только инфу про поддержку, но и прописывает конкретные ожидания по той или иной фиче и тесты для них.

Accessibility support

Линтеры и конфиги сборки

tsconfig

В tsconfig.json можно настраивать доступные фичи языка. С помощью target задаётся версия стандарта, а с ней и доступные методы массивов, глобальные объекты и многое другое. А с помощью lib можно доуточнить отдельные моменты.

ESLint

В ESLint есть всевозможные languageOptions и некоторые другие настройки, но я хотел рассказать о другом.

Есть плагин для конфигурирования версии браузеров, которые вы поддерживаете в своём проекте, eslint-plugin-baseline-js. Он относительно молодой, и ещё даже нет первой версии, но задумка интересная. Конечно, он ничего не может сделать с гибкостью JS, и в этом плане настройки tsconfig будут лучше:

// Ругается
Object.groupBy();

// Не ругается
const O = Object;
O.groupBy();

Ещё один плагин уже от авторов ESLint: @eslint/css. И да, он для линтинга CSS. В том числе есть встроенное правило про поддержку браузеров, use-baseline.

/* :has() есть не во всех браузерах */
h1:has(+ h2) {
    margin: 0 0 0.25rem 0;
}

StyleLint

Аналогичный плагин есть и для Stylelint, stylelint-plugin-use-baseline. По сути, тут стоит отталкиваться от того, что у вас используется для линтинга CSS, так что можно использовать или то, или то.

Также есть плагин stylelint-no-unsupported-browser-features. Он позволяет делать примерно тоже самое, но более точно задать список поддерживаемых браузеров:

"plugin/no-unsupported-browser-features": [
    true,
    {
        "browsers": ["> 1%", "Safari >= 14", "Chrome >= 84", "Firefox >= 86"],
        "ignorePartialSupport": true
    }
]

Другие инструменты и сборщики

browserlist, на который мы только что посмотрели, поддерживается большим количеством инструментов. Также в большом количестве инструментов есть target, который позволяет настраивать цель для сборки (будь то Vite, Webpack или что-то ещё).

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

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

Итого

Отслеживание работоспособности кода во всех поддерживаемых браузерах (и окружениях) становится всё более сложной задачей. Можно, конечно, тестировать каждый релиз в минимальных поддерживаемых версиях, но это достаточно затратно (и тоже не панацея).

В каких-то случаях поможет подход с прогрессивным улучшением. Но это может вести к неожиданным проблемам, как, например, в случае со starting-style (когда в определённых версиях Хрома браузер просто крашился).

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

Остаётся наше знание, с которым разработчики работают. Но остальные системы тоже не помешают, не забывайте)

Почитать ещё посты