Чи можна зробити стандартний Tailwind доступнішим вибором?

Якось мій проєкт почав «сипатися» так, що я не міг цього відтворити. Окремі секції злітали, колонки, що мали бути поруч, ставали в ряд, а картки виходили за межі екрана — і все це на стандартних розмірах viewport, які я перевіряв десяток разів. Мій CSS був у порядку. root font size — стандартні 16px. Зрештою я знайшов причину: користувач збільшив стандартний розмір шрифту в браузері, і breakpoints у Tailwind тихо масштабувалися разом із ним. Layout змінювався на вужчому viewport, ніж я розраховував.

Це наштовхнуло мене на думку, про яку я раніше не замислювався: якщо користувач змінить стандартний шрифт браузера, чи змістить це мої Tailwind breakpoints?

Здавалося б, це не має значення. Breakpoints стосуються viewport width, а розмір шрифту — тексту. Це різні площини. Але насправді вони пов’язані, і коли ви зрозумієте як, то замислитеся, чи справді стандартні налаштування Tailwind — це те, що вам потрібно. Скажу чесно: коли я вперше про це подумав, моя відповідь була помилковою.

Що Tailwind пропонує «з коробки»

Починаючи з Tailwind v3.2, стандартні breakpoints вказані в rem. У v4 це залишилося без змін:

sm   40rem   /* 640px  */
md   48rem   /* 768px  */
lg   64rem   /* 1024px */
xl   80rem   /* 1280px */
2xl  96rem   /* 1536px */

Отже, md:flex насправді означає @media (min-width: 48rem). Значення в пікселях у коментарях — це просто rem × 16. І в цьому × 16 криється вся суть.

Пастка: rem у media query працює не так, як ви думаєте

Ваша інтуїція підказує: «rem залежить від font-size кореневого елемента, тож якщо я задам html { font-size: 10px }, мої breakpoints зміняться».

А от і ні. Усередині media query condition одиниці rem та em взагалі не зважають на ваш CSS:

/* Це НЕ змінить поріг спрацьовування `min-width: 48rem`. */
html {
  font-size: 10px;
}

@media (min-width: 48rem) {
  /* Умова все одно розраховується відносно початкового (initial) font-size, */
  /* а не вашого html { font-size } */
}

Згідно зі специфікацією Media Queries Level 4, відносні одиниці в media queries розраховуються на основі initial value. Тобто CSS вашої сторінки тут безсилий.

Це перше, що всі дізнаються, і на цьому більшість статей зупиняється. Але це лише половина картини, і друга її частина набагато цікавіша.

Те, про що ніхто не згадує: користувач усе ще може їх змінити

«Initial value» не означає «завжди 16px». Це значення, з якого починає user agent, і користувач має на нього вплив:

• Налаштування font-size у браузері (Chrome: chrome://settings/fonts; Firefox: about:preferences). Це змінює initial value браузера. Отже, це зміщує ваші rem/em breakpoints.
• Author CSS (html { font-size }).
  Не зміщує їх. (Та сама пастка, про яку ми говорили вище).

Ось моя уточнена модель. Три різні способи «зробити більше» — три різні поведінки:

Це головний аргумент на користь Tailwind default. Це перемога в плані accessibility, і саме тому розробники обрали такий підхід.

Чому ж тоді у заголовку йдеться про «не завжди доступний»?

Тому що «добре для тексту» не завжди означає «добре для макета». Коли breakpoints залежать від розміру шрифту, ви передаєте контроль над layout налаштуванням, яких ви не бачите і не тестували. Ось де це може вилізти боком:

• Ви тестували при 16px. Ваш md:grid-cols-3 виглядав чудово. Але у користувача з шрифтом 20px сітка на 3 колонки увімкнеться на вужчому екрані, ніж ви планували, і картки просто не влізуть.
• Бібліотеки компонентів із жорсткими внутрішніми breakpoints можуть змінювати макет прямо під час скролу, що виглядає як баг.
• Це непомітно. Зум сторінки легко відтворити. Налаштування шрифту в браузері заховане глибоко, його рідко чіпають і майже ніколи не включають у тест-кейси. Коли воно ламає layout, відтворити проблему вкрай важко.

Це не означає, що rem breakpoints — це помилка. Це означає, що стандартні налаштування пропонують компроміс: краща реакція на преференції користувача, але менша передбачуваність для вас.

Реальна дискусія

То що ж обрати? Про це варто посперечатися.

px breakpoints гарантують, що layout спрацює саме на тій ширині, яку ви заклали в дизайн. Вони покладаються на page zoom (який масштабує все, включно з px), щоб забезпечити доступність. Це сильна позиція: зум — це те, чим користувачі реально користуються, і він чудово працює з px.

rem/em breakpoints додатково поважають налаштування default font-size. Це важливо для невеликої, але реальної групи користувачів, які замість зуму обирають більший базовий шрифт. Це також сильна позиція.

Тому питання не в тому, що «правильно», а в тому: для кого ви оптимізуєте проєкт і чи був це ваш свідомий вибір?

Ви обрали rem, бо думали про користувачів, які масштабують текст, чи просто залишили все як є? Хороший default — це той, який ви б обрали самі. Налаштування accessibility, яке ви не можете пояснити, — це просто налаштування.

Щодо стандартів

Часто кажуть, що px breakpoints порушують accessibility, але специфікація каже інше. WCAG 1.4.4 (Resize Text) вважається виконаним, якщо текст можна збільшити до 200% будь-яким доступним у браузері механізмом. W3C прямо вказує page zoom як достатню техніку. Оскільки зум масштабує пікселі без проблем, px breakpoints відповідають WCAG 1.4.4.

Отже, підтримка системного font-size — це не обов’язковий мінімум, а крок вперед. Обираючи rem, ви вирішуєте піти далі вимог WCAG. Це круто, але важливо бути чесним: це свідоме перевищення стандарту, а не просто «галочка» для комплаєнсу.

Як змінити налаштування

Перехід на px breakpoints у Tailwind v4 робиться через @theme:

/* app.css */
@import "tailwindcss";

@theme {
  --breakpoint-sm: 640px;
  --breakpoint-md: 768px;
  --breakpoint-lg: 1024px;
  --breakpoint-xl: 1280px;
  --breakpoint-2xl: 1536px;
}

Або у tailwind.config.js для v3:

/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    screens: {
      sm: "640px",
      md: "768px",
      lg: "1024px",
      xl: "1280px",
      "2xl": "1536px",
    },
  },
};

Можна піти й іншим шляхом: залишити rem і переконатися, що весь контент побудований на rem та протестований при 200% збільшенні тексту.

Суть не у відповіді

Суть у тому, що фраза «стандарти Tailwind інклюзивні» приховує багато нюансів. Варто розуміти, яку саме доступність ви отримуєте, а яку — ні, і чи збігається це з потребами ваших користувачів.
Отже: rem, em чи px для ваших breakpoints? Схоже, обидві сторони мають рацію.

Хочете перевірити самі? Поруч із цим постом є демо. Відкрийте його, змініть стандартний шрифт у браузері та подивіться, як rem breakpoint рухається, а px залишається на місці.

Джерела

• Media Queries Level 4, §6 "Using Units" (W3C) — про те, що одиниці в media queries залежать від initial font-size.
• Tailwind CSS: Responsive design — офіційна документація про rem у breakpoints.
• Tailwind CSS v3.2 release notes — коли стався перехід на rem.
• Tailwind CSS: Theme variables (@theme) — як перевизначати змінні у v4.
• Understanding WCAG SC 1.4.4: Resize Text (W3C / WAI) — критерії доступності щодо масштабування тексту.