Зачем мне эта тема сейчас
Когда появляется идея feature-floor, сразу хочется «официальный источник правды».
MDN browser-compat-data почти идеально ложится в эту роль — и почти так же идеально ломает лабораторию, если использовать его не по назначению.
Что такое BCD простыми словами
Это открытый репозиторий совместимости: какие API в каких браузерах и с какой версии. Машиночитаемый календарь. Не блог-пост. Не скриншот. JSON-память веба.
Для инженера это подарок: можно сверить свою матрицу «milestone ↔ API» с общественным знанием, а не держать её только в голове.
Зачем сверять milestone и API
Потому что матрица врёт тише, чем детектор.
Я могу честно измерить поверхность браузера и при этом нечестно интерпретировать измерение — если мой календарь устарел, если я перепутал desktop/mobile, если посчитал превью обязательным этажом.
BCD — офлайн-проверка «не соврал ли я себе».
Типичный ритуал:
- Взял гипотезу из release notes.
- Зафиксировал ожидаемый этаж.
- Сверил с BCD: когда фича реально стала стабильной.
- Только потом смотрю живой браузер.
Так календарь остаётся календарём. А измерение — измерением.
Почему runtime на BCD — плохая идея
Потому что BCD описывает мир «как принято считать в документации», а не «что прямо сейчас у этого пользователя».
Пользователь на канале с флагами. Корпоративная сборка с вырезанными поверхностями. Региональные отличия. Задержки между «появилось в notes» и «есть у 95% клиентов». Ошибки и лаги самого датасета.
Если тащить BCD в рантайм как оракул «ты бот», получится детектор документации, а не детектор согласованности.
Ещё хуже — смешать BCD с вердиктом. Тогда любое расхождение с таблицей становится моральным ярлыком. А расхождение часто означает: «моя модель мира неполная».
В дневнике лаборатории это важно этически. Я обещал не публиковать пороги и рецепты обхода. Но даже без них можно навредить методу: превратить общественный календарь в дубинку.
Как я держу границу
BCD — для калибровки матриц дома. Release notes — для первичного календаря. Живой браузер и телефонный baseline — для измерения. Детектор — для поиска противоречий слоёв, не для сверки с JSON как со священным текстом.
Три заметки подряд (UA → feature-floor → BCD) закрывают дугу «заявление vs измерение» на уровне грамотности. Дальше по плану — три комнаты одной правды: main, iframe, Worker.
Публичные опоры: https://github.com/mdn/browser-compat-data https://developer.chrome.com/release-notes/
Общедоступная рамка (ссылки)
Репозиторий mdn/browser-compat-data и заметки релизов Chrome/Firefox/WebKit — три ноги табуретки. Одна без двух других шатается: BCD может отставать, notes бывают маркетинговыми, WebKit живёт своим ритмом.
Что это меняет в детекте и/или в билде (без конкретики)
BCD помогает готовить вопросы до эксперимента. В runtime я слушаю фактическую поверхность. В билде не «подгоняю под строку BCD», а проверяю, не разъехалась ли поверхность с заявленной эпохой. Флаги, enterprise policies, частичные реализации и альтернативные движки на iOS в EU делают «BCD сказал» слабым вердиктом.
Чего я не скажу и почему
Не публикую автоматические правила вида «если BCD, то score». Это путь к ложной точности.
Короткий вывод от первого лица
BCD — календарь на стене лаборатории. Календарь не выносит приговор человеку за столом. Я сверяю даты офлайн и измеряю живое онлайн.
