Зачем мне эта тема сейчас
Если UA — заявление, то Web API — поверхность, по которой это заявление можно проверить.
Идея простая. Браузеры публикуют release notes. В заметках появляются новые API. Значит, «этаж» возможностей можно оценить не по цифре в строке, а по тому, что реально есть в рантайме.
Я называю это feature-floor — пол версии по возможностям.
Feature-detection vs парсинг версии
Парсинг версии отвечает на вопрос: «как браузер себя назвал?» Feature-detection отвечает на другой: «что он умеет прямо сейчас?»
Эти вопросы расходятся чаще, чем хочется SEO- и antifraud-практике.
Старый движок с новым UA — низкий этаж при высоком заявлении. Новый движок с урезанным или странным UA — высокий этаж при скромном бейдже. Флаги, превью, частичные реализации — этаж «с мезонином».
Публичные страницы вроде x-bot.tech показывают именно эту логику: смотреть на API и согласованность платформы, а не молиться на одну строку. Я разбираю идею как грамотность, не как копирование чужого продакшена.
Типы маркеров общими словами
В лаборатории полезно мыслить тремя корзинами — без внутренних имён флагов.
Строгие маркеры. API, которые к определённой ветке уже должны быть. Их отсутствие при высоком заявленном номере — сильное противоречие.
Опциональные. Фичи, которые зависят от платформы, политики, разрешений. Отсутствие само по себе слабо говорит.
Превью / экспериментальные. Есть у части пользователей, нет у других. На них нельзя вешать приговор.
Ошибка новичка — превратить весь календарь фич в чеклист «бот/не бот». Правильная привычка — искать противоречие этажа заявлению, а не коллекционировать «подозрительные отсутствия».
Откуда брать календарь
Не из головы и не из закрытого файла на ноутбуке, если цель — публичная грамотность.
Chrome release notes / New in Chrome. Firefox Releases на MDN. Блоги WebKit / Safari.
Плюс открытые учебные детекторы как пример метода, не как эталон истины.
Я специально не перечисляю здесь конкретные API «для проверки Chrome N». Список устаревает. Метод остаётся: заявление → ожидаемый этаж → измерение → расхождение.
Связка с прошлой заметкой
UA сказал «я высоко». Пол версии сказал «этаж ниже». Это не автоматически бот. Это дыра в рассказе.
Иногда дыра — устаревшая матрица у меня. Иногда — странная сборка. Иногда — приватность и отключённые поверхности.
Поэтому следующая заметка — про MDN browser-compat-data: как сверять календарь офлайн и почему нельзя тащить BCD прямо в рантайм-вердикт.
Публичные опоры: https://x-bot.tech/chrome/version1/ https://developer.chrome.com/release-notes/ https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases https://webkit.org/blog/
Общедоступная рамка (ссылки)
Календарь фич сверяю с Chrome release notes, Firefox Releases и WebKit blog. Практический публичный пример мышления — x-bot version1.
Что это меняет в детекте и/или в билде (без конкретики)
В детекте чаще пишу «поверхность похожа на эпоху N±», чем «версия доказана». В билде проверяю, не создаю ли поверхность одной эпохи при заявлении другой. Зеркала снова смотрят друг на друга. Ложная точность «версия = 131.4» мне менее полезна, чем интервал согласованности и список противоречий.
Чего я не скажу и почему
Не публикую таблицы внутренних маркеров, пороги и рецепты «как нарисовать пол версии под сайт».
Короткий вывод от первого лица
Feature-floor учит смирению: браузер — этаж возможностей, а не наклейка на коробке. Я калибрую этаж по открытым release notes и проверяю согласованность.
