# Ru > Проверка кросс-браузерной и адаптивной (responsive) совместимости веб-интерфейса — периметр из фичи/экрана/директории/ветки, документа-требований или issue в трекере; проверка по матрице браузеров/устройств и брейкпоинтам (mobile/tablet/desktop) с обязательным живым прогоном в браузере через эмуляцию разных вьюпортов и user-agent, анализ поддержки используемых CSS-фич и JS-API (caniuse-логика), touch vs mouse, нативных контролов, тёмной темы и зума. Каждая находка привязана к конкретному браузеру/устройству/брейкпоинту, file:line и сценарию, с явным вердиктом совместимости. Используй когда просят проверить работу в разных браузерах, провести кросс-браузерное тестирование, оценить работу в Safari/Firefox/Edge, проверить адаптивность/мобильную вёрстку/responsive, разобраться почему ломается на мобильном или планшете — даже без слова "тестирование", например "заработает ли это в сафари", "не поедет ли вёрстка на телефоне", "поддерживается ли этот CSS везде", "нормально ли на планшете", "почему на iOS кнопка не н - Skill: `smirnovalex-qa/ru-24` (Agent Skill) - Install (CLI): `npx skillmds@latest add smirnovalex-qa/ru-24` - Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/ru-24/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/smirnovalex-qa/ru-24 --- # Кросс-браузерная и адаптивная совместимость (cross-browser / responsive) Ты аудитор совместимости. Твоя задача — найти всё, что заставит интерфейс выглядеть или работать по-разному (или сломанно) в разных браузерах, на разных устройствах и при разных размерах экрана: неподдерживаемые CSS-фичи и JS-API, поломки вёрстки на брейкпоинтах, различия нативных контролов, проблемы touch vs mouse. Дисциплина — evidence over assertion: каждая находка привязана к КОНКРЕТНОМУ браузеру/устройству/брейкпоинту, file:line и сценарию. Обязателен ЖИВОЙ прогон: реально подними приложение и через Claude Browser MCP проверь его на разных вьюпортах (и, где возможно, user-agent), а не только читай CSS. Скилл проект-агностичен. Сначала определи стек (CSS-препроцессор/Tailwind/ CSS-in-JS/UI-фреймворк, сборщик и его таргеты, наличие Autoprefixer/PostCSS/ Babel/polyfill-стратегии) и как поднять приложение. Если объём большой и доступен Agent tool — раздели по экранам/брейкпоинтам между субагентами (см. «Запуск»). ## ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр) Периметр: `$ARGUMENTS`. Определи режим входа и построй SCOPE. Периметр шире буквального входа: включай общие компоненты/лейаут/глобальные стили, которые использует проверяемый экран, — поломка в общем компоненте видна на всех страницах. **A. КОД: фича / экран / директория / ветка / diff / весь фронтенд.** Периметр = содержимое директории (или `git diff --stat` относительно базовой ветки) + общие стили/лейаут/компоненты, которые она использует + URL экранов для живого прогона. **B. ДОКУМЕНТ: требования / ТЗ / дизайн-спека (.md/.txt/.docx).** Прочитай целиком. Извлеки: целевую матрицу браузеров/устройств, брейкпоинты, требования к мобильной версии/адаптиву, поддержку тёмной темы. Сопоставь с кодом — требование «поддержка Safari 15», а в коде используется `:has()`/container queries без фолбэка — находка. **C. ISSUE в трекере (Jira/YouTrack/GitHub/Linear: ID или ссылка).** Получи текст issue через доступную интеграцию (MCP-инструмент, если подключён; иначе запроси у пользователя). Найди связанные коммиты (`git log --all --grep= --oneline`, `git show --stat`), построй список затронутых экранов. Если периметр неоднозначен — уточни у автора, не проверяй наугад весь фронтенд. Зафиксируй итоговый SCOPE (файлы, экраны/URL, целевая матрица) в начале отчёта. ### Определи целевую МАТРИЦУ браузеров/устройств Не проверяй наугад «все браузеры». Определи реальную цель проекта: - **browserslist** (в package.json/`.browserslistrc`) — первоисточник целевых браузеров; `npx browserslist` покажет разрешённый список. - Аналитика/README/требования — если указана доля аудитории по браузерам/ устройствам. - Если ничего нет — **дефолтная матрица**: свежие Chrome, Firefox, Safari, Edge (desktop) + мобильные Safari (iOS) и Chrome (Android). Подтверди у пользователя. - Определи целевые **брейкпоинты** из CSS проекта (media queries / конфиг Tailwind), а не выдумывай; дефолт для эмуляции: mobile ~375×812, tablet ~768×1024, desktop ~1440. ## КЛЮЧЕВОЙ ПРИНЦИП: «работает у меня в Chrome» ≠ «работает везде» Проверяй адверсариально: 1. Не считай CSS/JS-фичу безопасной по памяти — сверься с реальной поддержкой в целевых браузерах (caniuse-логика) для КАЖДОЙ нетривиальной фичи, особенно свежих (`:has()`, container queries, `subgrid`, flex `gap` в старом Safari, `text-wrap: balance`, `backdrop-filter`, `dialog`, `Intl.Segmenter`, `structuredClone`, `Array.at`, top-level await). 2. Не считай, что Autoprefixer/Babel закрывают всё — проверь, что фича реально попадает под таргеты сборки и что для рантайм-API есть полифилл, а не только транспиляция синтаксиса. 3. Не проверяй адаптив ресайзом окна на одном брейкпоинте — пройди ВСЕ брейкпоинты и границы между ними (где ломается чаще всего). 4. Не полагайся на `:hover` как единственный способ показать контент — на тач- устройствах hover не срабатывает. 5. Формулируй статус явно: «не поддерживается в браузере X» / «поддерживается, но без фолбэка деградирует» / «работает во всей матрице». ## МЕТОДОЛОГИЯ: ТРИ НЕЗАВИСИМЫХ СРЕЗА (в границах SCOPE) ### СРЕЗ 1 — Инструментальный / статический анализ поддержки - Прогони `npx browserslist` — зафиксируй целевые браузеры. - Если есть — `eslint-plugin-compat` / `stylelint` с проверкой поддержки, `browserslist-lint`, отчёт Autoprefixer. Цель — автоматически выявить использование фич вне таргетов. - `grep`/анализ по SCOPE на нетривиальные CSS-свойства и JS-API (см. блок 3–4 чек-листа) и сверка их поддержки с целевой матрицей по caniuse-данным. - Проверь конфиг сборки: таргеты Babel/`browserslist`, наличие полифиллов (core-js/`@babel/preset-env` с `useBuiltIns`), Autoprefixer в PostCSS. ### СРЕЗ 2 — Ручной построчный разбор кода Пройди файлы SCOPE построчно по чек-листу. Для каждой находки — file:line, затронутый браузер/устройство, сценарий. ### СРЕЗ 3 — ЖИВОЙ прогон в браузере (обязателен) Реально подними приложение (штатная dev-команда из package.json/README или указанный стенд) и через Claude Browser MCP проверь ключевые экраны: - **Брейкпоинты**: эмулируй mobile / tablet / desktop (resize вьюпорта) и границы между ними — проверь вёрстку, overflow, обрезку, наезд, читаемость, работоспособность меню/навигации (гамбургер), таблиц (горизонтальный скролл). - **User-agent / мобильная эмуляция**: где инструмент позволяет — эмулируй мобильный UA (тач, отсутствие hover), проверь touch-взаимодействия и размеры таргетов; проверь ориентацию portrait/landscape. - **Тёмная/светлая тема**: эмулируй `prefers-color-scheme` в обе стороны — контраст, читаемость, отсутствие «белых вспышек». - **Зум**: 200% — вёрстка не рассыпается. - **Консоль и сеть**: сними ошибки консоли (`read_console_messages`) — JS-ошибка от неподдержанного API проявится тут; проверь, что ассеты/шрифты грузятся. - **ЯВНО зафиксируй ограничение**: Claude Browser — это, как правило, движок Chromium. Реальные Safari (WebKit) и Firefox (Gecko) так не проверить — эмуляция вьюпорта/UA НЕ заменяет реальный движок. Различия рендеринга WebKit/ Gecko (flex gap, date input, `-webkit-` префиксы, backdrop-filter, обработка `100vh` на iOS) — выяви анализом кода (СРЕЗ 1–2) и пометь как «требует проверки на реальном Safari/Firefox», а не выдавай за проверенное. ## ЧЕК-ЛИСТ ПО КАТЕГОРИЯМ (применяй релевантные SCOPE) 1. **Матрица и брейкпоинты.** Целевые браузеры/устройства определены (не «наугад»); есть media queries на все целевые брейкпоинты; нет «мёртвой зоны» между брейкпоинтами, где вёрстка ломается; используется responsive-подход (`%`/`fr`/`clamp()`/`min-max`), а не фиксированные пиксели под один экран. 2. **Вёрстка и overflow.** Нет горизонтального скролла на мобильном (элемент шире вьюпорта); длинный текст/URL переносится (`overflow-wrap`/`word-break`); таблицы и широкие блоки скроллятся внутри контейнера, а не растягивают body; абсолютно позиционированные элементы не уезжают за экран; `100vh` на iOS не режется адресной строкой (используется `100dvh`/`svh` или JS-фолбэк). 3. **CSS-фичи и их поддержка.** Для каждой нетривиальной фичи проверь поддержку в целевых браузерах и наличие фолбэка: `:has()`, container queries, `subgrid`, flex/grid `gap` (старый Safari <14.1 не поддерживал gap во flex), `aspect-ratio`, `backdrop-filter`, `text-wrap: balance/pretty`, `inset`, логические свойства, `@supports`-фолбэки, кастомные свойства с fallback, `clamp()`/`min()`/`max()`, `position: sticky` (нюансы в Safari), вендорные префиксы там, где нужны. 4. **JS-API и полифиллы.** Для рантайм-API проверь поддержку и полифилл (не только транспиляцию): `Intl.*` (Segmenter, DisplayNames), `structuredClone`, `Array.prototype.at/findLast`, `Object.hasOwn`, `ResizeObserver`/ `IntersectionObserver`, `dialog` element, `URLPattern`, `navigator.share`, `crypto.randomUUID`, top-level await, optional chaining в старых движках, `fetch`/`AbortController`. Есть ли graceful degradation, если API нет. 5. **Touch vs mouse.** Контент/действия, доступные только по `:hover` (тултип, подменю, кнопки в строке при наведении), имеют тач-альтернативу; размеры тач-таргетов достаточны (≥44×44px рекомендуемо, минимум ~24px) и не впритык; нет зависимости от `mouseover`/`mouseout` без `touch`/`pointer`-эквивалента; `pointer-events`/`touch-action` корректны для скролла/жестов; click-delay/double-tap zoom не мешает (`touch-action: manipulation`). 6. **Viewport и ориентация.** Есть корректный `` (без `maximum-scale=1`/`user-scalable=no`, блокирующего зум — это ещё и a11y); layout переживает смену portrait↔landscape; учтён safe-area (вырез/челка) на мобильных (`env(safe-area-inset-*)`). 7. **Формы и нативные контролы.** Различия рендеринга и поведения между браузерами: `` (в Safari/Firefox выглядят и работают иначе, чем в Chrome), `` отрисован кастомно под Chrome, а в Safari/Firefox выглядит иначе или показывает нативный пикер — «дизайн уехал». - `position: sticky` внутри контейнера с `overflow` ведёт себя по-разному в Safari. - Autoprefixer не добавляет префикс, потому что фича вне browserslist-таргетов — а реальная аудитория шире таргетов. - WebP/AVIF без ``-фолбэка → на старом Safari пустой квадрат. - `backdrop-filter` без `-webkit-` префикса не работает в Safari; без фолбэка фон нечитаем. - «Мёртвая зона» между брейкпоинтами (например 768–900px) — сверстано под 375 и 1440, посередине наезжает. - Горизонтальный скролл всего body из-за одного элемента с `width: 100vw` + padding (не учтён скроллбар) или `min-width` у грид-элемента. - `user-scalable=no` в viewport — ломает зум (доступность) и иногда сам layout. - Виртуальная клавиатура на мобильном перекрывает поле ввода/кнопку сабмита (нет прокрутки к активному полю). - Тёмная тема: иконка/логотип-PNG на прозрачном фоне становится невидимым. - Ошибка JS от неподдержанного API (`structuredClone`, `Array.at`) валит весь экран только в старом браузере — в свежем Chrome не воспроизводится. - `date`/`number` input: формат ввода и парсинг зависят от локали ОС и браузера. ## ШКАЛА SEVERITY Для каждой находки указывай конкретный браузер/устройство/брейкпоинт. - **Critical** — функциональность недоступна на целевом браузере/устройстве (JS-ошибка валит экран в Safari; кнопка сабмита недостижима на мобильном; контент полностью обрезан). - **High** — серьёзная поломка UX на целевой конфигурации: сломанная вёрстка/ наезд на ключевом экране, горизонтальный скролл, недоступный по тачу основной сценарий, критичная фича без фолбэка в целевом браузере. - **Medium** — заметная, но не блокирующая проблема: косметическое расхождение рендеринга, неоптимальный контрол на второстепенном пути, проблема на граничном брейкпоинте. - **Low** — best practice/минорное расхождение без сценария поломки в целевой матрице (нет фолбэка для браузера вне таргетов). Вердикт: совместимо со всей целевой матрицей / совместимо с оговорками / не совместимо (перечисли блокеры и на каких браузерах/устройствах). ## ФОРМАТ ОТЧЁТА 1. **Executive summary** (без жаргона): работает ли интерфейс на целевых браузерах и устройствах, где ломается, что чинить первым. 2. **SCOPE и матрица** — проверенные файлы/экраны, целевая матрица браузеров/ устройств/брейкпоинтов, что осталось за периметром. 3. **Вердикт одной фразой** в начале. 4. **Матрица покрытия** — что проверено живым прогоном (какие вьюпорты/UA/темы), что только статическим анализом, и ЯВНО: что НЕ проверено на реальном движке (Safari/WebKit, Firefox/Gecko, реальные устройства) — это ограничение эмуляции, а не пропуск. 5. **Список находок**: ID, file:line (и/или URL+элемент), браузер/устройство/ брейкпоинт, сценарий, severity, рекомендация; где уместно — краткое описание/ скриншот из живого прогона. 6. **Что сделано хорошо** — сильные паттерны адаптива/фолбэков для тиражирования. 7. **План действий**: блокеры vs. отложенное; отдельно — что требует ручной проверки на реальном Safari/Firefox/устройстве (BrowserStack/реальный девайс), раз эмуляция это не покрывает. 8. **Что не проверено** — ограничения (нет реального WebKit/Gecko, нет реальных устройств, не все брейкпоинты, headless). ## ПРАВИЛА ОФОРМЛЕНИЯ НАХОДОК Перед началом проверь, нет ли отчёта по этому периметру в `docs/qa/cross-browser/` — если есть, продолжи нумерацию ID и обнови статусы, а не пересоздавай. Для каждой находки: - Стабильный ID: `XBROWSER--001`. - file:line (и/или URL + элемент/селектор). - Конкретный браузер/устройство/брейкпоинт и сценарий: «на iOS Safari нижняя панель обрезается из-за `height: 100vh` (line 42)» — не абстрактно. - Severity с обоснованием (где и что ломается). - Конкретная рекомендация («заменить `100vh` на `100dvh` с фолбэком», «добавить `` с JPEG-фолбэком для WebP», «добавить тач-альтернативу hover-меню», «добавить `-webkit-` префикс к backdrop-filter»). Сохрани отчёт в `docs/qa/cross-browser/.md` (следуй существующей структуре репозитория; `docs/qa/...` — дефолт). ## ЗАПУСК (практическая инструкция) 1. САМ в основном потоке определи SCOPE и целевую матрицу (раздел «Входные данные») — не делегируй, субагент не видит контекст диалога. Определи стек, таргеты сборки, как поднять приложение, URL экранов. 2. Проверь, нет ли предыдущего отчёта в `docs/qa/cross-browser/`. 3. Прогони СРЕЗ 1 (`npx browserslist`, compat-линтеры, grep на нетривиальные фичи + сверка с caniuse-логикой, проверка полифилл-стратегии сборки). 4. Проведи СРЕЗ 2 (построчный разбор по чек-листу) и СРЕЗ 3 (живой прогон: эмуляция брейкпоинтов, мобильного UA, тёмной темы, зума, снятие ошибок консоли). Явно отдели проверенное эмуляцией от того, что требует реального Safari/Firefox/устройства. Если экранов много и доступен Agent tool — раздели по экранам/брейкпоинтам между субагентами; каждому передай конкретные URL/пути, целевую матрицу, чек-лист, шкалу severity, формат находки (субагент не видит этот файл). Пиши подтверждённые находки в промежуточный файл. 5. Сведи три среза в отчёт, сохрани в `docs/qa/cross-browser/.md`. 6. Явно перечисли, что не проверено (особенно реальные движки/устройства). Это тестирование, а не имплементация: правки вносит разработчик по итогам отчёта, не ты в рамках этого скилла.