Поверхности веб-платформы: карта проверки

Согласованность веб-платформы, это порядок проверки, а не один тест. Этот хаб связывает кластер платформы и добавляет ограниченную запись, где названа первая поверхность, расходящаяся с объявленным входом; начинайте с материала Матрицы тестов по платформам и версиям.

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

Кратко

• Разделите поведение на четыре поверхности: отрисовка и вёрстка, выполнение скриптов, сетевые согласования и доступ к возможностям.
• Записывайте объявленный вход рядом с наблюдаемым значением для одной версии и одной собственной страницы.
• Назовите первую поверхность с расхождением, остановитесь и передайте её владельцу.
• Сокращение, резерв и недоступность, допустимые состояния, а не сбои.

Содержание

• Четыре поверхности
• Пройдите по кластеру платформы
• Проведите одну ограниченную проверку
• Разберите первое расхождение
• Практический итог

Четыре поверхности

Отрисовка и вёрстка охватывают то, что страница рисует: шрифты, цвет, медиазапросы и реакцию документа на viewport. Страница, не одна поверхность. Это набор поверхностей, таких как document, iframe и Worker, которые браузер реализует отдельно: у каждой своя спецификация, свой ритм выпусков и свои режимы отказа. Спрашивая, поддерживает ли браузер приложение, команда на деле задаёт четыре вопроса сразу, и ответы могут расходиться. Разделение вопросов отличает проверку, которая заканчивается названным владельцем, от обсуждения, которое заканчивается догадкой. Выполнение скриптов охватывает то, что работает: загрузку модулей, Worker, идентичность между realms и долгоживущие контексты. Сетевые согласования охватывают то, что передаётся: заголовки запроса, политику ответа, требования безопасного контекста и междоменные границы. Доступ к возможностям охватывает то, что странице разрешено использовать: политику разрешений, датчики, хранилище и экспериментальные функции за origin trials.

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

Роль BotBrowser здесь узкая: он удерживает объявленный профиль согласованным между контекстами, чтобы расхождение в записи относилось к проверяемой поверхности, а не к неучтённой переменной. Чтобы сравнить движки и продукты, сначала прочитайте материал Движок браузера и браузерный продукт, а причину определяйте после.

Пройдите по кластеру платформы

• Матрицы тестов по платформам и версиям решают, какие сочетания вы действительно запускаете.
• Данные совместимости API и резервные пути охватывают обнаружение и постепенный резерв.
• Целостность API между realms разделяет глобальные объекты страницы, iframe и worker.
• Поддержка функции не равна её качеству отделяет наличие от поведения.
• Поведение WebAssembly на разных платформах охватывает поверхность скомпилированного выполнения.
• Измерение производительности через User Timing записывает длительности вместо их ощущения.
• Безопасные контексты: зачем нужен HTTPS объясняет условие, которое молча отключает функции.
• Политика одного источника и изоляция сайтов задаёт границу межповерхностных тестов.
• Медиазапросы: уважайте выбор пользователя рассматривает предпочтения как вход платформы.
• Устойчивость долгоживущих контекстов охватывает поверхность после первой минуты.

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

Кластер задаёт и общий словарь. «Поддержка», «совместимость», «согласованность» и «защита» означают разное: поддержка, есть ли возможность в выпуске, совместимость, работает ли резерв приложения, согласованность, совпадают ли два контекста одного профиля, защита, может ли страница использовать значение, чтобы выделить человека или устройство. Одно слово для всех четырёх делает проверку непередаваемой.

Проведите одну ограниченную проверку

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

{
  "runId": "platform-review-20261019-01",
  "declared": { "release": "Chrome 155", "profile": "fresh-temporary", "fixture": "app-shell@v7" },
  "observed": {
    "rendering": "matches-declared-media",
    "scriptExecution": "workers-available",
    "network": "request-headers-recorded",
    "capabilityAccess": "camera-denied"
  },
  "firstDifference": null,
  "testedOn": "2026-10-19"
}

Держите вне записи cookie, идентификаторы учётных записей, необработанные заголовки и любые результаты сторонних детекторов. Возможность, запрещённая намеренно,, объявленное состояние; запрещённая неожиданно, первое расхождение, и запись должна указывать, какой из случаев имел место.

Команда проверки вывела такую строку stdout:

{"slug":"browser-platform-surface-overview","linkedArticles":10,"svg":true,"docsReference":true}

Объявите версию до поверхности. Запишите версию браузера, класс профиля, версию фикстуры и политику приложения, которую команда намерена поддерживать. Объявленное значение, вход проверки, а не обещание того, что увидит страница. Когда вход рядом с наблюдением, у последующего расхождения есть точка отсчёта, а инженер поддержки отличает изменение платформы от фикстуры, отдавшей другой контент.

Одна страница на проверку. Проверка, которая переключает страницы между строками, не отделит расхождение поверхности от расхождения страницы. Загрузите одну собственную страницу, запишите её версию и читайте все строки из этого документа или из Worker, который она запустила намеренно. Если процессу нужны две страницы, проведите две проверки и свяжите их через runId, а не объединяйте строки.

Читайте поверхности в фиксированном порядке. Сначала отрисовку, потому что сломанная вёрстка часто объясняет всё дальнейшее. Затем выполнение скриптов, потому что сбой Worker или модуля выглядит как сетевая ошибка. Потом сетевые согласования, потому что заголовки и политика определяют, что странице разрешено. Последним, доступ к возможностям, потому что разрешения и датчики обычно сообщают своё состояние явно.

Отделяйте наличие от поведения. Конструктор может существовать и бросать ошибку при вызове; API может присутствовать, но возвращать сокращённое значение; разрешение может быть, а устройства, нет. Записывайте наличие и поведение в разные поля. Об этом подробнее в материале Поддержка не равна качеству; это самый частый источник ложного диагноза.

Записывайте сокращённые и недоступные состояния. Сокращённый user-agent, недоступный датчик и отклонённое разрешение, законные результаты браузера, уважающего приватность. Запись их как состояний, а не сбоев, удерживает проверку вокруг контракта приложения. Если приложению нужен недоступный параметр, это требование принадлежит объявленному входу, чтобы проверка падала по указанной причине.

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

Меняйте один вход за повтор. Зафиксируйте фикстуру, профиль и маршрут, затем измените одно объявленное значение. Обновление версии, смена профиля и смена политики, три эксперимента. Если два входа изменились вместе и строка расходится, запись не скажет, какой из них виноват, и следующему проверяющему придётся всё повторить. Это та же дисциплина, что матрицы тестов применяют к сочетаниям.

Повторяйте после значимого изменения. Запускайте карту заново при изменении версии, фикстуры, класса профиля или политики приложения и обновляйте testedOn вместо перезаписи прежней записи. Две записи с датами показывают, что и когда изменилось. Публичные стандарты и связанные статьи остаются источником определений.

Разберите первое расхождение

Если различается отрисовка, сравните фикстуру и таблицу стилей раньше версии. Если различается выполнение, проверьте, где работал код: на верхнем уровне, в iframe или в Worker. Если различается сеть, сравните заголовки и политику ответа, включая требования безопасного контекста. Если различается возможность, отделите объявленный отказ от неожиданного.

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

Расхождение в отрисовке, которое появляется только в одном языке, обычно относится к резервным шрифтам или метрикам текста, а не к версии; посмотрите font-family, font-size и запрошенные семейства раньше объявленной версии. Сравните тот же набор глифов до и после изменения и запишите, какие семейства запрашивались. Расхождение только в одном контексте, например в iframe или Worker, принадлежит владельцу этого контекста; верхняя страница может быть корректной, пока встроенный документ сбоит.

Расхождение в выполнении скриптов, исчезающее после перезагрузки, чаще оказывается проблемой жизненного цикла, а не платформы. Запишите, выполнялся ли скрипт до DOMContentLoaded, разрешился ли import и получил ли Worker вызов terminate(). Расхождение, появляющееся через несколько минут, относится к ресурсам и жизненному циклу; об этом рассказывает статья о долгих контекстах.

Сетевое расхождение, которое проявляется только за прокси или в контейнере, принадлежит владельцу транспорта раньше, чем браузеру. Сравните отдельно заголовки запроса, политику ответа и адрес выхода (https://example.com/echo). Обзор настройки прокси даёт карту такого решения и не позволяет отнести расхождение браузера к маршруту, который запрос вообще не передавал.

Расхождение в возможностях, которое выглядит как молчаливый сбой, обычно связано с политикой разрешений или безопасным контекстом, а не с отсутствием API. Проверьте, разрешена ли функция на странице (window.isSecureContext, пустой заголовок Permissions-Policy или предыдущий результат denied из navigator.permissions.query()), и не отказали ли пользователь или профиль раньше. Только после этих трёх проверок расхождение относится к владельцу платформы.

Каждая проверка отвечает на один вопрос и даёт одну строку в записи. Ценность порядка в том, что последующие проверки проще: когда отрисовка и выполнение стабильны, сетевое расхождение остаётся единственным объяснением, и проверке не нужно возвращаться к поверхностям, которые уже совпали.

Практический итог

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

Источники

• W3C: HTML Standard, определение origin
• MDN: политика безопасности контента CSP
• MDN: заголовок Cross-Origin-Embedder-Policy
• WHATWG: Workers
• W3C: рекомендации по доступности веб-контента
• MDN: возможности медиазапросов
• Документация BotBrowser: обзор отпечатка