Вступ: чому браузери досі "не домовились між собою"

Здавалося б, 2024 рік. Веб-стандарти існують десятиліттями. W3C публікує специфікації, браузери мають їх дотримуватись. Чому ж тоді сайт, що виглядає ідеально в Chrome, може "розвалитись" у Safari або показувати артефакти в Firefox?

Відповідь — у природі веб-розробки. Кожен браузер — це окремий продукт зі своїм рушієм рендерингу, своєю командою розробників і своїм темпом впровадження нових стандартів. Chrome використовує Blink, Firefox — Gecko, Safari — WebKit. Навіть Microsoft Edge, який нині базується на Chromium (тобто теоретично той самий рушій, що і Chrome), час від часу поводиться інакше.

Додайте до цього мобільні браузери (Safari на iOS, Samsung Internet, вбудовані WebView), корпоративні середовища де й досі трапляються старі версії IE або Edge Legacy, і картина стає ще строкатішою.

За даними Statcounter, на квітень 2026 року розподіл браузерів виглядає приблизно так: Chrome — близько 65%, Safari — 19%, Edge — 5%, Firefox — 3%, інші — 8%. Але це глобальна статистика. Для вашого конкретного сайту вона може відрізнятись — тому перший крок до крос-браузерної розробки завжди починається з аналізу вашої аудиторії.

У цій статті — системний підхід до крос-браузерної сумісності: від розуміння проблеми до конкретних інструментів тестування та технічних рішень, які забезпечують однакову роботу сайту в усіх середовищах.

Частина 1: Розуміння проблеми — чому сайти ламаються в різних браузерах

Різні рушії рендерингу

Рушій рендерингу — це серце браузера, відповідальне за перетворення HTML, CSS і JavaScript на те, що бачить користувач на екрані.

Blink (Chrome, Edge, Opera, Samsung Internet, більшість Android-браузерів) — найпоширеніший рушій. Розробляється Google. Відносно швидко впроваджує нові CSS та Web API.

WebKit (Safari на macOS та iOS, всі браузери на iOS) — і це ключовий момент: Apple вимагає, щоб всі браузери на iOS використовували WebKit. Тобто Chrome на iPhone — це насправді WebKit із Chrome-інтерфейсом. Firefox на iPad — WebKit під капотом. Це означає, що тестування "в Chrome на мобільному" не замінює тестування в реальному Safari на iOS.

Gecko (Firefox) — розробляється Mozilla. Відомий суворішим дотриманням стандартів і певними специфічними поведінками у CSS.

Різні темпи підтримки функцій

Нові CSS-властивості та JavaScript API спочатку з'являються в одних браузерах, і лише згодом — в інших. Наприклад:

• CSS Container Queries з'явились у Chrome 105 (серпень 2022), Safari 16 (вересень 2022), Firefox 110 (лютий 2023).
• CSS subgrid — Safari реалізував раніше за Chrome.
• scroll-behavior: smooth — довго не підтримувався Safari без поліфілу.
• WebP-зображення — Safari підтримує лише з версії 14 (2020).

Тобто між виходом специфікації та повноцінною підтримкою у всіх браузерах може минути від кількох місяців до кількох років.

Різна обробка помилок і граничних випадків

Браузери по-різному реагують на "неправильний" або неоднозначний код. Chrome може "виправити" помилку і відобразити так, як ви задумали. Firefox може відобразити інакше. Safari — зовсім по-третьому. Це особливо стосується:

• Margin collapsing у CSS (коли і як відступи "зливаються");
• Flexbox і Grid при граничних значеннях;
• Відображення шрифтів і підрядкові метрики;
• Обробка дат і часових зон у JavaScript;
• Поведінка форм і типів інпутів.

Мобільні vs Десктопні браузери

Мобільні браузери мають додаткові специфіки:

• iOS Safari — власна адресна панель, яка "ховається" при скролі, впливає на реальну висоту viewport. Відома проблема з 100vh — він не відповідає видимій висоті екрана.
• Масштабування — деякі мобільні браузери автоматично масштабують контент або текст.
• Touch-події — різна поведінка touchstart, touchmove, click (затримка 300 мс у старих браузерах).
• Keyboard — поява екранної клавіатури змінює розміри viewport, що може "ламати" fixed-елементи.

Частина 2: Стратегія крос-браузерної розробки

Визначте цільові браузери

Перше і найважливіше: не намагайтесь підтримувати всі браузери однаково. Це неможливо, непрактично і дорого. Натомість — визначте конкретний список браузерів на основі даних.

Де взяти дані:

Google Analytics (або будь-яка інша аналітика) показує, якими браузерами і пристроями користуються відвідувачі вашого сайту. Це має бути основним джерелом рішень.

Якщо сайт новий і даних ще немає — орієнтуйтесь на галузеву статистику для вашої географії та аудиторії. Для України та країн СНД частка мобільного Safari (iOS) традиційно висока через популярність iPhone серед платоспроможної аудиторії.

Практичний підхід: три рівні підтримки

Рівень A (повна підтримка): сайт виглядає і працює ідеально. Всі функції доступні. Регулярне тестування.

Рівень B (функціональна підтримка): сайт виглядає прийнятно, всі ключові функції працюють, але дрібні візуальні відмінності допустимі. Тестування перед релізом.

Рівень C (базова підтримка): контент доступний і читаємий, основні дії можливі, але візуальна відповідність не гарантується. Тестування по запиту.

Progressive Enhancement vs Graceful Degradation

Два підходи до роботи з браузерною сумісністю, які часто плутають.

Progressive Enhancement (прогресивне покращення) — починаєте з базової версії, що працює скрізь, і додаєте покращення для більш сучасних браузерів. Основа — семантичний HTML, базовий CSS. Поверх — покращення для браузерів, що підтримують нові функції.

Приклад: базова навігація — прості посилання, що працюють без JavaScript. Покращення — анімована мобільна навігація для браузерів із підтримкою CSS animations і JS.

Graceful Degradation (граціозна деградація) — починаєте з повнофункціональної "ідеальної" версії і забезпечуєте, щоб у старих браузерах все одно щось показувалось. Тобто — від кращого до гіршого.

Що краще? Для більшості сучасних проектів — Progressive Enhancement. Він природно призводить до більш стійкого коду: якщо щось не підтримується, сайт просто не показує цю функцію, а не "ламається". Але на практиці в сучасних командах часто поєднують обидва підходи залежно від конкретного компонента.

Feature Detection замість Browser Detection

Стара шкільна практика: перевіряти, який браузер відкрив сторінку (if (navigator.userAgent.includes('Safari'))), і на цій основі застосовувати різний код. Це — погана практика.

Причини:

• User-agent рядки легко підробляються;
• Нові версії браузерів можуть підтримувати функцію, яку ви "заблокували" для цього браузера;
• Код стає крихким і важко підтримуваним.

Правильний підхід: Feature Detection — перевіряти не браузер, а наявність конкретної функції.

CSS Feature Detection через @supports:

/* Базовий варіант для всіх */
.container {
  display: flex;
}

/* Покращений варіант для браузерів із підтримкою Grid */
@supports (display: grid) {
  .container {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  }
}

JavaScript Feature Detection:

// Перевірка підтримки Intersection Observer
if ('IntersectionObserver' in window) {
  // Використовуємо сучасний API
  const observer = new IntersectionObserver(callback);
} else {
  // Fallback — простіша реалізація без lazy loading
  loadAllImages();
}

Modernizr — бібліотека, що автоматично перевіряє підтримку десятків функцій і додає відповідні класи до

. Хоча в 2024–2025 роках потреба в ній зменшилась (браузери стали сучасніші), для проектів із широкою підтримкою старих браузерів вона ще актуальна.

Частина 3: CSS — найпоширеніше джерело крос-браузерних проблем

CSS Reset та Normalize

Різні браузери мають різні стилі за замовчуванням (user agent styles).

в Chrome і Safari може мати різний margin.виглядає по-різному в різних системах.

 

CSS Reset (Eric Meyer Reset, Josh Comeau Modern Reset) — "обнуляє" всі браузерні стилі за замовчуванням. Ви починаєте з чистого аркуша і повністю контролюєте стилізацію.

/* Спрощений Modern CSS Reset */
*, *::before, *::after {
  box-sizing: border-box;
}

* {
  margin: 0;
  padding: 0;
}

img, picture, video, canvas, svg {
  display: block;
  max-width: 100%;
}

input, button, textarea, select {
  font: inherit;
}

Normalize.css — не обнуляє, а нормалізує: встановлює однакові розумні значення за замовчуванням для всіх браузерів, зберігаючи корисні стандартні стилі. Менш радикальний підхід.

Що вибрати: для нових проектів — сучасний CSS Reset (Josh Comeau's або аналог). Для проектів, де потрібна сумісність зі старим кодом — Normalize.css.

Вендорні префікси: де вони ще потрібні

Вендорні префікси (-webkit-, -moz-, -ms-) — механізм, через який браузери впроваджували експериментальні CSS-функції до їх стандартизації. У 2024–2025 роках більшість сучасних CSS-властивостей вже не потребують префіксів. Але є винятки.

Де префікси ще актуальні:

/* Clip-path — webkit-prefix все ще рекомендується для Safari */
.element {
  -webkit-clip-path: polygon(0 0, 100% 0, 100% 85%, 0 100%);
  clip-path: polygon(0 0, 100% 0, 100% 85%, 0 100%);
}

/* Backface-visibility */
.card {
  -webkit-backface-visibility: hidden;
  backface-visibility: hidden;
}

/* Text size adjust на мобільних */
html {
  -webkit-text-size-adjust: 100%;
  text-size-adjust: 100%;
}

Autoprefixer — PostCSS-плагін, який автоматично додає потрібні вендорні префікси на основі вашого цільового списку браузерів (Browserslist). Якщо ви використовуєте сучасний build tool (Vite, Webpack, Parcel) — налаштуйте Autoprefixer і забудьте про ручне додавання префіксів.

// package.json або .browserslistrc
"browserslist": [
  "> 1%",
  "last 2 versions",
  "not dead"
]

Flexbox і Grid: крос-браузерні нюанси

Flexbox і CSS Grid підтримуються всіма сучасними браузерами, але є тонкощі:

Flexbox на Safari:

• gap для Flexbox підтримується Safari лише з версії 14.1 (2021). Для старіших версій доведеться використовувати margin.
• flex: 1 без явного flex-basis поводиться по-різному — завжди вказуйте повну форму: flex: 1 1 0%.

CSS Grid:

• subgrid — Safari реалізував раніше Chrome, але Firefox підтримував ще раніше.
• grid-template-columns: repeat(auto-fill, minmax(min(250px, 100%), 1fr)) — техніка, яка може поводитись по-різному в різних браузерах.

Практична порада: використовуйте caniuse.com для перевірки підтримки конкретних властивостей перед використанням у продакшні.

Проблема iOS Safari та 100vh

Одна з найвідоміших крос-браузерних проблем: height: 100vh на iOS Safari не дорівнює висоті видимого viewport, тому що Safari враховує адресний рядок (який ховається при скролі) у розрахунку 100vh.

Результат: елементи з height: 100vh "виходять" за межі екрана на мобільному Safari.

Рішення 1: CSS Custom Property через JavaScript

function setViewportHeight() {
  document.documentElement.style.setProperty(
    '--vh', `${window.innerHeight * 0.01}px`
  );
}
setViewportHeight();
window.addEventListener('resize', setViewportHeight);

.fullscreen-section {
  height: calc(var(--vh, 1vh) * 100);
}

Рішення 2: нові CSS viewport units (2023+)

/* svh — small viewport height (мінімальна висота, з урахуванням UI браузера) */
/* lvh — large viewport height (максимальна, коли UI прихований) */
/* dvh — dynamic viewport height (змінюється разом з UI) */
.section {
  height: 100dvh; /* Підтримується в сучасних браузерах */
}

dvh підтримується Chrome 108+, Safari 15.4+, Firefox 101+. Для старих браузерів — fallback через JavaScript.

Скролбари в різних ОС і браузерах

На Windows скролбари за замовчуванням займають місце і впливають на layout. На macOS і iOS вони накладаються поверх контенту і не займають місця. Це може призводити до "стрибків" layout або різного відображення.

/* Стилізація скролбарів (Webkit) */
::-webkit-scrollbar {
  width: 8px;
}

::-webkit-scrollbar-track {
  background: #f1f1f1;
}

::-webkit-scrollbar-thumb {
  background: #888;
  border-radius: 4px;
}

/* Стандартний CSS scrollbar (Firefox) */
html {
  scrollbar-width: thin;
  scrollbar-color: #888 #f1f1f1;
}

---

Частина 4: JavaScript — крос-браузерні підводні камені

Підтримка сучасних JS-функцій

JavaScript, на відміну від CSS, розвивається через специфікацію ECMAScript (ES2015, ES2016, ... ES2024). Нові синтаксичні конструкції (?. optional chaining, ?? nullish coalescing, async/await) не підтримуються старими браузерами.

Babel — компілятор JavaScript, що перетворює сучасний JS-код у зворотньо сумісний варіант. Наприклад, async/await → Promise-ланцюжки, arrow functions → звичайні функції, let/const → var.

Налаштовується через .babelrc або babel.config.js, використовує той самий Browserslist для визначення цільових браузерів.

// .babelrc
{
  "presets": [
    ["@babel/preset-env", {
      "targets": "> 0.5%, last 2 versions, not dead",
      "useBuiltIns": "usage",
      "corejs": 3
    }]
  ]
}

Поліфіли: заповнення прогалин

Поліфіл (polyfill) — код, що реалізує функціональність, яка відсутня в старому браузері. На відміну від Babel (що трансформує синтаксис), поліфіли додають відсутні методи та API.

core-js — найповніший набір поліфілів для ECMAScript: Array.from, Object.assign, Promise, fetch тощо.

Intersection Observer поліфіл:

import 'intersection-observer'; // поліфіл для старих браузерів

Fetch API поліфіл:

import 'whatwg-fetch';

Стратегія полідоповнення: не завантажуйте поліфіли для всіх. Використовуйте polyfill.io — сервіс, що динамічно визначає, які поліфіли потрібні конкретному браузеру, і надсилає тільки їх.

Специфічні JavaScript-проблеми Safari

Safari (і особливо iOS Safari) відомий як "новий IE" серед веб-розробників через відставання у підтримці певних Web API:

IndexedDB — had issues в старих версіях Safari, поводився непередбачувано в приватному режимі.

WebRTC — обмежена підтримка деяких функцій на iOS.

Service Workers та PWA — Safari значно обмежує можливості PWA: немає push-сповіщень у старих версіях, обмежене зберігання, неможливість додавання на домашній екран через маніфест (до Safari 17).

Clipboard API — navigator.clipboard.writeText() вимагає жесту користувача у Safari, інакше кидає помилку.

автовідтворення відео — Safari вимагає атрибут muted для автовідтворення.

Атрибут playsinline обов'язковий для iOS, інакше відео відкривається на повний екран.

Обробка подій: крос-браузерні нюанси

Подія input vs change: input спрацьовує при кожній зміні значення (під час введення), change — після завершення. Поведінка change для деяких типів відрізняється між браузерами.

Passive Event Listeners: для touch-подій і wheel рекомендується { passive: true } для кращої продуктивності. Але якщо ви не знаєте про цю опцію — браузер може виводити попередження.

element.addEventListener('touchstart', handler, { passive: true });

requestAnimationFrame: використовуйте замість setTimeout для анімацій — більш стабільна поведінка у всіх браузерах.

---

Частина 5: Шрифти та типографіка між браузерами

Рендеринг шрифтів: чому текст виглядає по-різному

Навіть якщо шрифт однаковий, рендеринг тексту може відрізнятись через:

• Font smoothing (згладжування): macOS і Windows використовують різні алгоритми; iOS і Android — теж різні.
• Subpixel rendering: на Windows із певними налаштуваннями текст рендериться через субпіксельне згладжування.
• Line-height обчислення: різні браузери трохи по-різному обчислюють висоту рядка.

/* Покращення рендерингу тексту */
body {
  -webkit-font-smoothing: antialiased; /* macOS/iOS */
  -moz-osx-font-smoothing: grayscale; /* Firefox на macOS */
  text-rendering: optimizeLegibility;
}

Важливо: -webkit-font-smoothing: antialiased робить текст тоншим на macOS. Для жирних шрифтів це часто краще виглядає. Але для дуже тонких шрифтів може знизити читабельність. Тестуйте на реальних пристроях.

Variable Fonts (варіативні шрифти)

Variable Fonts — один файл шрифту, що підтримує весь діапазон жирності, курсиву тощо. Підтримуються всіма сучасними браузерами, але для старих браузерів потрібні fallback-варіанти.

@font-face {
  font-family: 'MyFont';
  src: url('font-variable.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: swap;
}

/* Fallback для старих браузерів */
@supports not (font-variation-settings: normal) {
  @font-face {
    font-family: 'MyFont';
    src: url('font-regular.woff2') format('woff2');
    font-weight: 400;
  }
}

---

Частина 6: Форми та інтерактивні елементи

Стилізація форм: найважчий фронт крос-браузерної боротьби

Форми — одна з найскладніших областей для крос-браузерного CSS. Браузери мають сильну думку щодо того, як мають виглядати , , , .

— найважчий для стилізації елемент. Стрілка вибору, відступи, шрифт — все це різниться між браузерами та ОС.

 

/* Базова крос-браузерна стилізація select */
select {
  appearance: none;
  -webkit-appearance: none;
  background-image: url("data:image/svg+xml,..."); /* кастомна стрілка */
  background-repeat: no-repeat;
  background-position: right 12px center;
  padding-right: 36px;
}

Чекбокси та radio-кнопки — традиційно неможливо стилізувати напряму через CSS. Є два підходи:

1. Приховати оригінальний елемент і стилізувати псевдоелемент через ::before/::after.
2. Використовувати нову CSS-властивість accent-color:

/* Сучасний підхід — accent-color */
input[type="checkbox"],
input[type="radio"] {
  accent-color: #6200ea; /* Колір акценту */
  width: 18px;
  height: 18px;
}

accent-color підтримується Chrome 93+, Firefox 92+, Safari 15.4+.

 

— відображення і функціональність відрізняються кардинально. На iOS — нативний date picker; на Firefox — інший вигляд. Якщо вам потрібна однакова поведінка — використовуйте JavaScript date picker (Flatpickr, Pikaday).

Placeholder: колір placeholder-тексту стилізується через нестандартні псевдоелементи:

::placeholder {
  color: #9e9e9e;
  opacity: 1; /* Firefox додає opacity: 0.54 за замовчуванням */
}

Focus Styles — доступність та крос-браузерність

outline: none — класична помилка, яка псує як доступність, так і крос-браузерну поведінку. Замість видалення outline — стилізуйте його:

/* Сучасний підхід із focus-visible */
:focus {
  outline: none; /* Прибираємо для mouse-кліків */
}

:focus-visible {
  outline: 3px solid #6200ea;
  outline-offset: 2px;
}

:focus-visible показує стиль фокусу тільки при навігації клавіатурою, але не при кліку мишею. Підтримується всіма сучасними браузерами.

Частина 7: Медіа та зображення між браузерами

елемент для крос-браузерних зображень

Браузер бере перший , який він підтримує. Цей підхід забезпечує оптимальний формат для кожного браузера без JavaScript.

SVG: крос-браузерні особливості

SVG загалом добре підтримується, але є нюанси:

та external references: посилання на зовнішній SVG-файл через має проблеми в Edge Legacy та Safari старших версій. Альтернатива — inline SVG або SVG sprite вбудований у HTML.

viewBox та preserveAspectRatio: деякі браузери по-різному трактують preserveAspectRatio, що може призводити до різного масштабування SVG.

Фільтри та ефекти: filter: drop-shadow() на SVG-елементах може рендеритись по-різному.

Відео та медіа

Частина 8: Інструменти тестування та налагодження

Локальне тестування

BrowserStack — хмарна платформа для тестування на реальних пристроях і браузерах. Понад 3000 комбінацій браузер/ОС/пристрій. Є live-тестування (підключення до реального пристрою) і автоматизоване (Selenium/Cypress тести). Платна, але є безкоштовний trial.

Sauce Labs — аналог BrowserStack, популярний для CI/CD інтеграції.

LambdaTest — дещо дешевша альтернатива з хорошим набором браузерів.

VirtualBox або Parallels з Windows VM — для тестування Edge і Chrome на Windows. Microsoft безкоштовно надає образи Windows VM для розробників.

Xcode Simulator — якщо у вас Mac, Xcode включає симулятор iOS/iPadOS з Safari. Не замінює тестування на реальному пристрої, але добре для швидких перевірок.

Chrome DevTools для налагодження

Device Mode — симуляція різних розмірів екранів і дотикових пристроїв. Не замінює реальне тестування, але корисний для швидкого виявлення layout-проблем.

Coverage Tab — показує, який відсоток вашого CSS і JS справді використовується. Незамінний для виявлення зайвого коду.

Rendering Tab — дозволяє симулювати різні умови рендерингу:

• Emulate CSS media features (prefers-color-scheme, prefers-reduced-motion);
• Показувати layout shift regions;
• Показувати paint flashing.

Accessibility Tree — перевірка доступності, яка часто корелює з крос-браузерними проблемами.

Firefox Developer Tools

Firefox має деякі унікальні DevTools-функції:

Grid Inspector — найкращий інструмент для відладки CSS Grid. Візуально показує всі grid-лінії, зони, gaps.

Flexbox Inspector — аналогічно для Flexbox.

Shape Path Editor — для редагування clip-path та shape-outside прямо в браузері.

Font Inspector — детальна інформація про шрифти, застосовані до елементів.

Автоматизоване тестування

Playwright — сучасний інструмент від Microsoft для end-to-end тестування. Нативно підтримує Chrome, Firefox і WebKit (Safari). Дозволяє запускати однакові тести в трьох різних рушіях — ідеально для крос-браузерного тестування.

// playwright.config.js
const { defineConfig, devices } = require('@playwright/test');

module.exports = defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'Mobile Chrome', use: { ...devices['Pixel 5'] } },
    { name: 'Mobile Safari', use: { ...devices['iPhone 13'] } },
  ],
});

Cypress — популярний e2e фреймворк, але підтримує тільки Chrome-подібні браузери (і Firefox). Для WebKit — потрібен Playwright.

Visual Regression Testing — автоматичне порівняння скриншотів між браузерами. Інструменти: Percy, Chromatic, Applitools, або Playwright з вбудованим screenshot comparison.

// Playwright visual comparison
test('Homepage looks correct', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveScreenshot('homepage.png');
});

Частина 9: Build Tools та конфігурація для крос-браузерності

Browserslist — єдина конфігурація для всіх інструментів

Browserslist — стандарт конфігурації цільових браузерів, який використовується Autoprefixer, Babel, ESLint, PostCSS та іншими інструментами.

# .browserslistrc
> 0.5%          # Браузери з часткою ринку понад 0.5%
last 2 versions # Останні 2 версії кожного браузера
not dead        # Виключити браузери без офіційної підтримки
iOS >= 12       # iOS Safari 12 і новіше

Перевіряйте, які браузери покриває ваша конфігурація: npx browserslist.

PostCSS — потужна обробка CSS

PostCSS — інструмент для трансформації CSS через плагіни:

Autoprefixer — автоматичне додавання вендорних префіксів.

postcss-preset-env — дозволяє використовувати майбутні CSS-функції вже сьогодні, автоматично додаючи поліфіли та fallback. Аналог Babel для CSS.

// postcss.config.js
module.exports = {
  plugins: [
    require('autoprefixer'),
    require('postcss-preset-env')({
      stage: 2,
      features: {
        'nesting-rules': true,
        'custom-properties': true
      }
    })
  ]
};

Vite та Webpack: конфігурація для сумісності

Vite (сучасний стандарт):

// vite.config.js
import legacy from '@vitejs/plugin-legacy'

export default {
  plugins: [
    legacy({
      targets: ['defaults', 'not IE 11'],
      additionalLegacyPolyfills: ['regenerator-runtime/runtime']
    })
  ]
}

@vitejs/plugin-legacy автоматично генерує два бандли: сучасний (ESM) для нових браузерів і legacy (CommonJS + поліфіли) для старих. Браузери самі вибирають потрібний через