Breakpoint має виходити з контенту, а не з назви пристрою

Адаптивний макет часто починають будувати з готового списку: телефон, планшет, настільний екран. Потім для кожної назви підбирають умовну ширину на кшталт 768px, 1024px або 1280px.

Проблема в тому, що браузер не знає, що таке "планшет". Він знає тільки доступну ширину.

У реальному інтерфейсі чату дві колонки могли починатися надто рано, вкладення мали фіксовану ширину, а bubble разом із бічними кнопками переставав поміщатися ще до умовної межі для планшета.

Саме тому breakpoint краще вибирати не за назвою пристрою, а за моментом, коли конкретний layout перестає бути коректним.

Для повідомлення в чаті мінімальна ширина може складатися не лише з bubble.

У рядку одночасно можуть бути:

• аватар;
• відступ між аватаром і повідомленням;
• сам bubble;
• кнопки reply, reaction або menu;
• зовнішні відступи контейнера.

Якщо сума цих частин більша за доступну ширину, layout уже потребує зміни незалежно від того, який це пристрій.

Не обов’язково рахувати все математично до одного пікселя, але така модель змушує дивитися на реальні обмеження.

Якщо для нормального вигляду потрібно приблизно 860px, breakpoint у 768px уже запізнюється. Якщо layout комфортно працює до 700px, немає сенсу ламати його лише тому, що "почався tablet".

У chat UI окремою проблемою можуть бути вкладення. Наприклад, картка документа має фіксовані 320px, а bubble ще має внутрішні відступи й бічні кнопки.

На широкому екрані це непомітно. Але ближче до межі двоколонкового layout саме attachment card може стати елементом, який першим перестає поміщатися.

Тоді breakpoint визначає не "розмір планшета", а мінімальна ширина найбільш вимогливого контенту.

Кнопки реакцій, відповіді або додаткового меню часто візуально сприймаються як щось "поза bubble". Через це їх легко не врахувати під час оцінки ширини.

Але CSS layout усе одно повинен знайти для них місце.

Якщо bubble має max-width: 70%, а праворуч ще стоїть група controls, реальна доступна ширина для тексту менша, ніж здається з одного правила 70%.

Те саме стосується layout із двома колонками.

Припустімо, одна колонка містить список діалогів, друга - активний чат. Якщо обидві мають мінімально комфортну ширину, між ними є gap, а зовнішній контейнер ще має padding, breakpoint можна отримати з цих значень.

Число 880px у такому прикладі не є універсально правильним. Воно правильне тільки якщо саме біля цієї ширини конкретна композиція починає стабільно поміщатися.

В іншому проєкті це може бути 840px, 960px або взагалі інше значення.

Практично це часто робиться дуже просто:

1. відкрити layout у широкому стані;
2. повільно зменшувати viewport;
3. знайти перший момент, де елементи починають стискатися неприродно;
4. перевірити, який саме елемент створив обмеження;
5. поставити breakpoint трохи раніше цього моменту;

Так breakpoint народжується з поведінки контенту, а не з таблиці "популярних пристроїв".

Не кожна проблема потребує нового media query.

Іноді layout ламається через min-width: auto у flex/grid child, довгий текст, фіксовану ширину вкладення або елемент, якому не дозволили стискатися.

Перш ніж створювати нову точку перелому, варто переконатися, що базовий layout справді гнучкий.

Назви пристроїв можуть бути зручними в документації або дизайн-системі, але вони не повинні бути джерелом технічного рішення.

Сучасний телефон у landscape може бути ширшим за маленьке вікно desktop-браузера. Планшет із split screen може мати менше місця, ніж очікує "tablet breakpoint".

Тому CSS повинен реагувати на доступний простір, а не на припущення про тип пристрою.

Точка перелому адаптивного макета не повинна існувати лише тому, що так заведено для планшета або настільного екрана.

Він потрібен у точці, де поточна композиція перестає нормально працювати: колонки стають надто вузькими, вкладення не поміщаються, bubble конфліктує з controls або контент починає переповнювати контейнер.

Найкраща точка перелому - це не назва пристрою, а найменша ширина, на якій конкретний layout ще залишається коректним.