Інтерфейс Toast-сповіщень на CSS: стекування, анімації, варіанти розміщення

Що таке toast-сповіщення (і чим воно не є)

Toast — це тимчасове сповіщення, яке підтверджує, що щось відбулося. Це не діалог. Це не повідомлення про помилку форми. Це не запит дозволу. Воно має з’являтися, давати достатній контекст і тихо зникати, не вимагаючи уваги.

Чистий ментальний образ: toast — це рядок логів у шкіряному інтерфейсі. Ви очікуєте, що він буде впорядкований, обмежений за частотою та читабельний. Якщо він гучний, нав’язливий або блокує користувача — ви фактично побудували модальне вікно з проблемами відмови.

Є друге, менш гламурне завдання: toasts — інструмент для бюджету помилок. Вони показують повторні спроби, часткові відмови та знижені режими без того, щоб руйнувати робочий процес. Але це працює лише якщо вони поводяться послідовно на сторінках, у модалках і в джунглях z-index.

Жарт №1: Toast, який не можна закрити — це просто модал, що пішов в мистецтво.

Цікаві факти та коротка історія

Toasts здаються винайденими разом із сучасними веб-застосунками. Насправді ні. Паттерн існує в UI-системах десятиліттями.

• Android популяризував термін «Toast» як примітив UI у ранніх версіях платформи, і це вплинуло на те, як веб-розробники говорять про тимчасові повідомлення.
• Ранні десктопні програми використовували «balloon tips» у системному треї; ідея була та сама: тимчасовий статус без блокування роботи.
• Термін «toast» прижився, бо воно «вискакує й зникає» — невелике швидке повідомлення, а не повноцінна тривога.
• Веб-UI спершу покладалися на alert(), бо браузери давали це безкоштовно; воно навчило покоління переривати користувачів без причини.
• CSS трансформи стали стандартом для анімацій, бо вони зазвичай уникають перерахуунку макета і зменшують підвисання.
• Зростання SPA зробив глобальні системи повідомлень необхідними; переходи сторінок більше не скидали стан, тому черги стали важливі.
• Safe-area інсети з’явилися з вирізами та закругленими кутами; тости, що їх ігнорують, виглядають нормально на десктопі і жахливо на iPhone.
• prefers-reduced-motion став загальноприйнятим очікуванням після багатьох скарг на вестибулярні ефекти; ігнорувати його — тепер реальна помилка доступності.

«Сподівання — не стратегія.» — General Gordon R. Sullivan

Можете сподіватися, що ваші toasts не зіштовхнуться з іншими оверлеями. Або ж спроектувати так, щоб цього не сталося.

Примітиви розмітки: контейнер, стек і безпечні зони

Якщо ви хочете надійні toasts, припиніть розкидати їх по випадкових компонентах. Дайте їм дім: виділену область toast, яка позиціонується відносно вікна перегляду, а не від того, який flexbox обгортає ваш контент сьогодні.

Контракт контейнера

Контейнер toast має:

• Мати position: fixed (або іноді absolute всередині відомого кореня), щоб закріпитися відносно вікна перегляду.
• Мати прогнозовані inset і підтримувати безпечні зони.
• Не перехоплювати кліки зі сторінки, хіба що сам toast потребує цього.
• Визначати максимальну ширину і дозволяти перенос рядків.

CSS-скелет, якому можна довіряти

cr0x@server:~$ cat toast.css
:root{
  --toast-gap: 10px;
  --toast-edge: 12px;
  --toast-max-width: 420px;
  --toast-z: 1000; /* You’ll still need a z-index policy. */
}

.toast-region{
  position: fixed;
  z-index: var(--toast-z);
  inset: var(--toast-edge);
  display: flex;
  flex-direction: column;
  gap: var(--toast-gap);
  pointer-events: none;

  /* Safe-area: protect against notches + rounded corners */
  padding:
    calc(env(safe-area-inset-top) + 0px)
    calc(env(safe-area-inset-right) + 0px)
    calc(env(safe-area-inset-bottom) + 0px)
    calc(env(safe-area-inset-left) + 0px);
}

.toast{
  pointer-events: auto;
  width: min(var(--toast-max-width), 100%);
  background: rgba(20,25,34,.95);
  border: 1px solid rgba(39,50,68,.9);
  border-radius: 12px;
  box-shadow: 0 14px 40px rgba(0,0,0,.5);
  padding: 10px 12px;
}

Зверніть увагу на хід, який рятує від випадкового блокування кліків: регіон отримує pointer-events: none, окремі тости відновлюють взаємодію. Це різниця між «приємним UX» і «чому я не можу натиснути кнопку оформлення».

Безпечні зони: трактуйте мобільні пристрої як продакшн, а не демо

На телефонах з вирізами видимий viewport не завжди дорівнює доступному. env(safe-area-inset-*) існує не просто так. Якщо його ігнорувати, ваші toasts сховаються під вирізом і виглядатимуть зламаними. Ще гірше — вони стануть частково неклікабельними, що дає інтермітентні баги, залежні від пристрою та орієнтації.

Стекування: порядок, відступи та політики максимальної видимості

Стекування — це не «просто flexbox». Це продуктове рішення, яке стає операційним, коли бекенд генерує 20 помилок за п’ять секунд. Потрібні правила: порядок, максимальна кількість видимих, поведінка при спаду та політика закриття.

Виберіть порядок і дотримуйтеся його

Виберіть одне:

• Найновіші зверху: підходить для зворотного зв’язку про стан. Користувач бачить останню дію першою.
• Найновіші знизу: підходить для хронологічних історій. Стек росте вниз як журнал подій.

Що б ви не обрали, зафіксуйте це в CSS і порядку DOM. Не намагайтеся «виправити» це трансформами й негативними відступами; саме так ви отримаєте дивний порядок фокуса і екранні рідери, які оголошують повідомлення в невідповідній послідовності.

Використовуйте gap, а не margin або абсолютні зсуви

Використовуйте display: flex і gap. Це чисто, зрозуміло і не накопичує багів з відступами, коли тости змінюють висоту.

Плануйте «шторм toast-ів»

Шторми тостів трапляються. Їх викликають повторні спроби, цикли валідації, масові дії або сервіс, який на короткий час повертає 429, і UI ввічливо промовляє кожну спробу.

Встановіть максимум видимих (зазвичай 3–5). Якщо більше, то:

• Згорніть у один toast: «ще 5 повідомлень…» з можливістю відкрити панель.
• Чергуйте і показуйте пізніше, але обережно: відкладені помилки можуть з’явитися після того, як користувач пішов, і виглядати як паранормальне явище.

Відступи і читабельність: проектуйте для змінного контенту

Toast може бути «Збережено» або багаторядковим поясненням часткової помилки. Розмітка має витримувати перенос рядків. Використовуйте min() для ширини і дозволяйте висоті рости природно. Не обрізайте висоту, якщо не даєте кнопку «ще»; інакше ви заховаєте єдину корисну частину повідомлення.

Варіанти розміщення без копіювання CSS

Вам потрібні варіанти розміщення. Продукт попросить. Потім підтримка попросить. Потім ваше власне здоровеці попросить, бо bottom-center на мобільному відрізняється від top-right на десктопі.

Неправильний підхід — окремий CSS-файл для кожного варіанту. Правильний підхід: один компонент регіону, розміщення керується data-атрибутами і невеликою кількістю CSS-змінних.

Визначайте розміщення як вирівнювання, а не координати

Думайте в термінах:

• Головна вісь (flex-direction)
• Вирівнювання перехресної осі (align-items)
• Де сидить регіон (top/bottom/left/right через inset)

cr0x@server:~$ cat toast-placements.css
.toast-region{
  --_x: end;          /* start | center | end */
  --_y: start;        /* start | end */
  --_dir: column;     /* column | column-reverse */
  --_inset-top: var(--toast-edge);
  --_inset-right: var(--toast-edge);
  --_inset-bottom: var(--toast-edge);
  --_inset-left: var(--toast-edge);

  position: fixed;
  z-index: var(--toast-z);
  top: var(--_inset-top);
  right: var(--_inset-right);
  bottom: var(--_inset-bottom);
  left: var(--_inset-left);

  display: flex;
  flex-direction: var(--_dir);
  gap: var(--toast-gap);
  pointer-events: none;

  justify-content: flex-start;
  align-items: flex-end;
}

/* placements */
.toast-region[data-placement="top-right"]{
  --_inset-bottom: auto;
  --_inset-left: auto;
  --_dir: column;
  align-items: flex-end;
}
.toast-region[data-placement="top-left"]{
  --_inset-bottom: auto;
  --_inset-right: auto;
  --_dir: column;
  align-items: flex-start;
}
.toast-region[data-placement="bottom-right"]{
  --_inset-top: auto;
  --_inset-left: auto;
  --_dir: column-reverse;
  align-items: flex-end;
}
.toast-region[data-placement="bottom-center"]{
  --_inset-top: auto;
  left: var(--toast-edge);
  right: var(--toast-edge);
  bottom: var(--toast-edge);
  --_dir: column-reverse;
  align-items: center;
}

.toast{
  pointer-events: auto;
  width: min(var(--toast-max-width), 100%);
}

Два важливі моменти для продакшну:

• Нижні стеки зазвичай хочуть column-reverse, щоб нові toasts з’являлися ближче до краю, а не під старими, де користувач їх не помітить.
• Bottom-center потребує обмежень повної ширини через лівий/правий inset і align-items: center; інакше ви все життя будете сперечатися «чому це не по центру?».

Уникайте «респонсивної рулетки розміщень»

Деякі команди переміщують регіон toast за брейкпоінтами: top-right на десктопі, bottom-center на мобільному. Це може бути нормально. Але робіть це свідомо і зберігайте послідовність напрямку анімації (про це пізніше). Користувачі помічають, коли повідомлення «телепортується» з кута в кут між сторінками або орієнтаціями.

Анімації: швидкі, оборотні та коректні

Анімації toast-ів — це місце, де благі наміри часто вмирають. Toast має з’являтися швидко, не привертати надто багато уваги і ніколи не робити інтерфейс повільнішим, ніж він є.

Використовуйте transform + opacity, а не властивості макета

Анімація top, height або margin примусово викликає перерахунок макета. На сторінці з реальною роботою (таблиці, графіки, липкі заголовки) це викликає підвисання. Дотримуйтеся transform і opacity для самого toast.

Вхід і вихід мають бути симетричними

Коли toast закривається, він має зникати так само, як з’явився. Симетрія зменшує відчуття «що щойно сталося?».

cr0x@server:~$ cat toast-motion.css
.toast{
  transform-origin: top right;
  will-change: transform, opacity;
}

.toast[data-state="entering"]{
  animation: toast-in 220ms cubic-bezier(.2,.9,.2,1) both;
}

.toast[data-state="exiting"]{
  animation: toast-out 180ms cubic-bezier(.2,.9,.2,1) both;
}

@keyframes toast-in{
  from{ opacity: 0; transform: translateY(-8px) scale(.98); }
  to{ opacity: 1; transform: translateY(0) scale(1); }
}

@keyframes toast-out{
  from{ opacity: 1; transform: translateY(0) scale(1); }
  to{ opacity: 0; transform: translateY(-6px) scale(.98); }
}

@media (prefers-reduced-motion: reduce){
  .toast[data-state="entering"],
  .toast[data-state="exiting"]{
    animation: none;
  }
}

Блок з prefers-reduced-motion не опціональний. Це ваша угода «без сюрпризів» з користувачами, у яких рухові анімації викликають запаморочення. Ставте це так само серйозно, як таймаути: невелика конфігурація, яка запобігає непропорційній кількості інцидентів.

Анімація, що враховує напрямок (без створення 12 варіантів)

Якщо ви розміщуєте toasts внизу, ймовірно, ви хочете, щоб вони піднімалися трохи, а не падали зверху як цеглина. Це можна зробити однією змінною для Y-зсуву.

cr0x@server:~$ cat toast-directional-motion.css
.toast-region{ --toast-enter-y: -8px; --toast-exit-y: -6px; }

.toast-region[data-placement^="bottom"]{
  --toast-enter-y: 8px;
  --toast-exit-y: 6px;
}

@keyframes toast-in{
  from{ opacity: 0; transform: translateY(var(--toast-enter-y)) scale(.98); }
  to{ opacity: 1; transform: translateY(0) scale(1); }
}

@keyframes toast-out{
  from{ opacity: 1; transform: translateY(0) scale(1); }
  to{ opacity: 0; transform: translateY(var(--toast-exit-y)) scale(.98); }
}

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

Жарт №2: Якщо ваша анімація toast триває довше, ніж API-виклик — вітаю, ви побудували підсилювач затримки інтерфейсу.

Шарування та контексти стекування: податок z-index

Більшість багів із toast в реальних застосунках пов’язані не з компонентом самого toast. Вони пов’язані з контекстами стекування. Конкретно: toast на своєму місці, але позаду чогось. Або попереду того, що не має перебувати попереду. Або він зникає, коли батьку застосовано transform.

Розберіться з ворогом: контексти стекування

Новий контекст стекування може створюватися такими речами:

• position з z-index (у певних комбінаціях)
• transform
• filter
• opacity < 1
• isolation: isolate
• contain: paint (і родичі)

Якщо ваш регіон toast знаходиться всередині піддерева з будь-яким із цих, ваш «глобальний оверлей» стає локальним. Ось коли модалки «з’їдають» toasts, або toasts з’являються позаду липкого заголовка з героїчним z-index: 999999.

Виберіть політику шарування як дорослий

Ось політика, що виживає у середніх та великих додатках:

• Визначте невелику шкалу z-index в одному місці (токени): base, dropdown, sticky, modal, toast, tooltip.
• Рендерте регіон toast якомога ближче до <body> (шаблон portal), щоб він не був у пастці батьківських контекстів стекування.
• Ніколи не «вирішуйте» шарування випадковими величезними числами. Це як додавати більше рівнів RAID, бо перший відчував себе самотнім.

Виберіть порядок, який відповідає семантиці вашого продукту. Головне — щоб це було задокументовано, поділене і застосоване. Інакше кожна команда винаходитиме своє, і ваш z-index перетвориться на звалище.

Події вказівника та поведінка при натисканні

Toasts плавають над контентом. Іноді це нормально. Іноді це ламає основний заклик до дії у найгірший момент. Виправлення рідко в «перемістити toast». Зазвичай це «припинити контейнер перехоплювати введення».

Контейнер має пропускати кліки

Встановіть pointer-events: none на регіон і pointer-events: auto на toast. Це робить порожній простір регіону прозорим для кліків.

Зробіть інтерактивні toasts навмисно інтерактивними

Якщо toast має дії (Відмінити, Повторити), він має бути доступним з клавіатури і для зчитувачів екрану. Це означає:

• Кнопки дій — це реальні button.
• Закриття — це кнопка, а не div з onClick і молитвою.
• Стан фокуса має бути видимим.

Якщо toast лише інформаційний, розгляньте зробити його неінтерактивним, щоб уникнути випадкових натискань. Не ставте кнопку закриття на все підряд «бо так роблять toasts». Якщо він автозакривається і безпечний — нехай буде прозорим.

Доступність: live-регіони, фокус і зчитувачі екрану

Toasts — пастка для доступності, бо вони тимчасові і не завжди виникають у відповідь на явну дію користувача. Потрібно вирішити, як їх оголошувати, і уникати крадіжки фокуса, якщо це не критичне повідомлення.

Правильно використовуйте ARIA live-регіони

Звичайний паттерн:

• Успішні/інформаційні toasts: aria-live="polite"
• Помилки: aria-live="assertive" лише коли це терміново

«Assertive» може переривати зчитувачі екрану. Використовуйте його як виклик на чергування інженера: лише коли це дійсно важливо.

Не крадіть фокус для стандартних toast-ів

Крадіжка фокуса ламає форми і навігацію клавіатурою. Якщо користувач вводить текст у полі, і ви різко переводите фокус на toast — ви створюєте помилку доступності і податок на продуктивність.

Але забезпечте спосіб дістатися до них

Якщо toasts містять дії, користувачі мають мати розумний шлях до них. Два робочі підходи:

• Кнопка повідомлень, що відкриває панель з недавніми toast-ами (клавіатурна навігація).
• Посилання «Перейти до повідомлень» для клавіатурних користувачів у додатках, де toasts критичні й часті.

Також: поважайте налаштування руху користувача. Це теж доступність. Якщо ви анімуєте — ви несете відповідальність за наслідки.

Продуктивність і надійність: уникайте хвиль перевикликів макета

Toasts маленькі. Тому команди стають недбалими. Потім вони розміщують їх на кожній сторінці, і раптом шторм toast-ів перетворюється на вечірку головного потоку.

Що справді шкодить

• Анімація властивостей макета.
• Вимірювання DOM кожного кадру для обчислення зсувів стеку.
• Малювання десятків тіней з блюром на малопродуктивних пристроях.
• Тригеринг перерахунку стилів шляхом перемикання глобальних класів на body для кожного toast.

Що масштабується добре

• Використовуйте flex layout + gap; без ручної математики стекування.
• Анімуйте кожен toast лише transform/opacity.
• Обмежуйте видимі toasts; згорніть переповнення.
• Надавайте перевагу одному контейнеру зі стабільним набором CSS; змінюйте лише data-атрибути для стану.

Блюр і тіні: використовуйте помірковано

Фільтри блюру можуть бути дорогими. Великі box-shadow — теж. Ви можете зберегти вигляд «плаваючої картки» без танення GPU мобільних пристроїв, використовуючи помірні тіні й уникаючи backdrop blur, якщо не тестували на слабких пристроях.

Три корпоративні історії з польових умов

Міні-історія №1: Інцидент через неправильне припущення

Одна продуктова команда випустила нову систему toast-ів як частину редизайну. Усе виглядало чудово в storybook. На десктопі теж виглядало чудово. Вони вважали, що позиціювання «глобальне», бо рендерили його всередині компоненту макета сторінки, який використовувався на всіх маршрутах.

Потім платіжний потік додав «secure step» обгортку, яка застосувала transform: translateZ(0) для плавності переходу. Та ця обгортка також тримала iframe з віджетом верифікації зі своїми правилами шарування. Регіон toast опинився всередині трансформованого елементу і перестав поводитись як справжній оверлей вікна перегляду.

Симптоми були дивними: іноді toast з’являвся позаду віджета верифікації; іноді обрізався кордоном обгортки; іноді мав зсув. Підтримка доповідала про «відсутні повідомлення про помилку», що змушувало інженерів на дзвінку затримувати погляд на кілька секунд.

Неправильне припущення було простим: «position: fixed завжди відноситься до viewport». Не завжди — трансформи змінюють це відношення. Виправлення не було у великому z-index. Виправлення — перемістити регіон toast з трансформованого піддерева (портал до кореня документа) і задокументувати правило: «ніяких трансформів на корені додатка, якщо ви не контролюєте всі оверлеї».

Міні-історія №2: Оптимізація, що призвела до проблем

Інша організація вирішила «оптимізувати» перформанс toast-ів, передобчислюючи висоти і позиціонуючи кожен toast абсолютно з translateY зсувом. Ідея: ніякого макета, лише трансформи. Навіть додали will-change скрізь, бо «це робить анімації плавнішими».

Це працювало в демках. Працювало з одним-двома toast-ами. Потім у продакшні інтеграція спричинила пачку попереджень після масового імпорту. Тости мали різну довжину тексту, деякі переносилися, деякі — ні. Передобчислена висота була неправильною, коли шрифти завантажувалися пізніше, при локалізації або при збільшенні масштабу сторінки.

Стек зсунувся. Тости накладалися. Анімації закриття залишали діри. Ще гірше — «will-change скрізь» піднімав занадто багато шарів, що збільшило використання пам’яті і погіршило прокрутку на середньоцінових пристроях.

Виправлення було нудним: повернутися до flexbox + gap, прийняти, що макет існує, і обмежити видимі toasts. Реальний приріст продуктивності прийшов від невідображення 20 тостів з важкими тінями, а не від імітації макета за допомогою хитрої математики.

Міні-історія №3: Нудна, але правильна практика, що врятувала день

Одна команда мала письмову політику шарування. Нічого феєричного: короткий документ і файл з токенами z-index. Toast-і рендерилися в корені документа. Модалки мали визначені рівні. Тултіпи теж. Всі скаржилися, що це «процес».

Потім відбувся масштабний редизайн: нова навігація, новий липкий хедер, нова панель пошуку, нові модалки для онбордингу. Тиждень, коли кожен MR зачіпав CSS. Команда очікувала багів шарування. Їх майже не було.

Коли баг і з’явився (тултіп рендерився під toast), виправлення було швидким, бо політика показувала, хто винен: токен z-index тултіпа був застосований неправильно в одному компоненті. Ніяких загадок. Ніяких ескалацій. Ніякого «в мене працює».

Нудна практика врятувала день, бо звузила простір рішень. У роботі з надійністю це безцінно.

Практичні завдання з командами: інспект, відтворення, рішення

Ви не можете SRE-вати CSS-баги, але можете діагностувати їх професійно. Нижче — практичні завдання, які можна виконувати під час розробки чи CI, щоб діагностувати проблеми з toast. Кожне містить команду, що означає вивід і рішення.

Завдання 1: Підтвердити, що CSS для toast дійсно збирається (перевірка бандла)

cr0x@server:~$ ls -lh dist/assets | grep -E 'toast|main'
-rw-r--r-- 1 cr0x cr0x 312K Nov 12 09:14 main.8c1b1a.css
-rw-r--r-- 1 cr0x cr0x  14K Nov 12 09:14 toast.2a9f0c.css

Що це означає: stylesheet для toast існує і виробляється збіркою.

Рішення: якщо відсутній — проблема в збірці/конфігурації, а не в логіці CSS. Виправте порядок імпортів або налаштування бандлера, перш ніж лізти в z-index.

Завдання 2: Перевірити порядок імпортів CSS (проблема прихованих переопредилень)

cr0x@server:~$ rg -n "toast\.css|toast\.scss|@import.*toast" src
src/app.tsx:7:import "./toast.css";
src/app.tsx:8:import "./app.css";

Що це означає: стилі toast завантажуються перед app styles; app стилі можуть їх переоприділяти.

Рішення: якщо app.css містить загальні правила типу button{} або .card{}, ви можете випадково перекривати стилі toast. Поміняйте порядок або підвищіть специфічність свідомо (не випадково).

Завдання 3: Підтвердити, що регіон рендериться в корені документа (перевірка порталу)

cr0x@server:~$ rg -n "createPortal|#toast-root|toast-root" src
src/ui/toast/ToastProvider.tsx:22:return createPortal(region, document.getElementById("toast-root")!);
src/index.html:15:<div id="toast-root"></div>

Що це означає: у вас є виділена точка монтовання DOM і портал.

Рішення: якщо цього немає — швидше за все ви розміщуєте toasts у компонентному дереві, яке набуде трансформів/overflow і почне їх класти.

Завдання 4: Виявити випадкове обрізання через overflow у оболонці додатка

cr0x@server:~$ rg -n "overflow:\s*(hidden|clip|auto)" src/layout
src/layout/AppShell.css:41:overflow: hidden;
src/layout/Content.css:12:overflow: auto;

Що це означає: частини вашого макета створюють контексти обрізання.

Рішення: якщо toasts рендеряться всередині таких елементів — вони будуть обрізані. Перемістіть регіон toast в body/portal або видаліть overflow: hidden з предків, якщо це можливо.

Завдання 5: Знайти трансформи, що створюють пастку для fixed-позиції

cr0x@server:~$ rg -n "transform:|filter:|opacity:\s*0\." src/layout src/pages
src/layout/SecureWrap.css:9:transform: translateZ(0);
src/pages/Onboarding.css:18:opacity: 0.98;

Що це означає: ці правила можуть створювати контексти стекування; трансформи можуть впливати на поведінку fixed-елементів в залежності від структури.

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

Завдання 6: Підтвердити, що токени z-index централізовані, а не хаотичні

cr0x@server:~$ rg -n "z-index:\s*[0-9]{4,}" src
src/components/LegacyModal.css:3:z-index: 99999;
src/components/HelpWidget.css:8:z-index: 1000000;

Що це означає: хтось самовільно використовує величезні z-index.

Рішення: замініть на значення з токенів; інакше ваша політика z-index стане перегонами озброєнь.

Завдання 7: Перевірити захоплення pointer-events, що блокує UI сторінки

cr0x@server:~$ rg -n "pointer-events:\s*(auto|none)" src/ui/toast
src/ui/toast/toast.css:12:pointer-events: none;
src/ui/toast/toast.css:24:pointer-events: auto;

Що це означає: регіон пропускає кліки, toasts інтерактивні.

Рішення: якщо такої розбивки немає — виправте перед релізом. Баги з блокуванням кліків видно користувачам миттєво.

Завдання 8: Переконатися, що підтримка reduced-motion присутня

cr0x@server:~$ rg -n "prefers-reduced-motion" src/ui/toast
src/ui/toast/toast-motion.css:21:@media (prefers-reduced-motion: reduce){

Що це означає: ви поважаєте налаштування руху користувача.

Рішення: якщо відсутня — додайте. Це не полірованість; це запобігання регресіям доступності і скаргам через рух.

Завдання 9: Переконатися, що ви не анімуєте властивості макета

cr0x@server:~$ rg -n "@keyframes|transition:" src/ui/toast
src/ui/toast/toast-motion.css:9:animation: toast-in 220ms cubic-bezier(.2,.9,.2,1) both;

Що це означає: у вас є анімації. Тепер перевірте, що саме вони анімують.

Рішення: якщо ви знайдете top, height або margin в keyframes — рефакторьте на transform/opacity, щоб зменшити підвисання і трясіння макета.

Завдання 10: Підтвердити, що обробка safe-area присутня

cr0x@server:~$ rg -n "safe-area-inset" src/ui/toast
src/ui/toast/toast.css:16:padding: calc(env(safe-area-inset-top) + 0px) ...

Що це означає: регіон toast не буде ховатися під вирізами і закругленими кутами.

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

Завдання 11: Використовувати Lighthouse CI для виявлення регресій від штормів toast-ів

cr0x@server:~$ npx lighthouse http://localhost:4173 --only-categories=performance --view=false
Performance: 86
First Contentful Paint: 1.4 s
Total Blocking Time: 220 ms
Cumulative Layout Shift: 0.02

Що це означає: у вас є базові показники продуктивності.

Рішення: якщо Total Blocking Time зростає після додавання ефектів (фільтри, великі тіні) — зменшіть їх. Toast-и не варті повільнішого додатка.

Завдання 12: Профілювати шторм toast-ів у headless Chrome (трасування)

cr0x@server:~$ node scripts/toast-storm.js
Rendered 50 toasts in 2.3s
Main-thread long tasks: 7
Worst long task: 182ms

Що це означає: рендеринг/анімації спричиняють довгі задачі під навантаженням.

Рішення: обмежте видимі toasts, приберіть дорогі ефекти і переконайтеся, що JS не вимірює макет при кожному кадрі.

Завдання 13: Переконатися, що сервер не надсилає CSP, який блокує inline-стилі (якщо ви на них покладаєтеся)

cr0x@server:~$ curl -I http://localhost:8080 | rg -i "content-security-policy"
Content-Security-Policy: default-src 'self'; style-src 'self'; script-src 'self'

Що це означає: стилі обмежені самохостингом. Inline-стилі заблоковані.

Рішення: якщо ваша система toast інжектить inline-стилі для розміщення/анімації, вона може впасти в продакшні. Надавайте перевагу CSS-класам/data-атрибутам замість inline-стилів.

Завдання 14: Перевірити, що регіон toast існує лише один раз (немає дублікатів)

cr0x@server:~$ rg -n "id=\"toast-root\"" -S .
./src/index.html:15:<div id="toast-root"></div>

Що це означає: у вас є один кореневий контейнер.

Рішення: якщо у шаблонах є кілька коренів — ви будете рендерити кілька регіонів і дивуватися, чому toasts дублюються. Виправте шаблони/макети перш ніж іншим.

Швидкий план діагностики

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

Перше: чи видимий він і на своєму місці?

• Перевірте присутність в DOM: чи взагалі є елемент toast у DOM?
• Перевірте обчислену позицію: чи регіон має position: fixed і прив’язаний там, де очікується?
• Перевірте обмеження viewport: чи його не обрізує overflow або трансформований предок?

Якщо він відсутній: це проблема рендерингу/стану (логіка JS, mount порталу, умовне рендерення), а не CSS.

Якщо присутній, але не на місці: це проблема розміщення контейнера або пастка fixed-позиції через трансформи.

Друге: чи позаду або над невірним елементом?

• Інспект контексти стекування: шукайте трансформи, opacity, фільтри на предках.
• Аудит політики z-index: чи щось використовує z-index: 999999 і перемагає?

Якщо він за модаллю: вирішіть, чи це коректна поведінка продукту. Потім відкоригуйте токени z-index. Не використовуйте випадкові числа.

Третє: чи ламає це введення або доступність?

• Події вказівника: чи можна клікати крізь порожній простір регіону?
• Клавіатура: чи можна табнути далі без пасток фокуса?
• Зчитувач екрану: чи оголошує він повідомлення ввічливо, а не спамить?

Якщо він блокує кліки: виправте pointer-events на контейнері.

Якщо краде фокус: перестаньте фокусувати toasts за замовчуванням; використайте панель для повідомлень з постійним станом.

Четверте: чи підвисає все під навантаженням?

• Тест шторму toast-ів: відрендерте 20–50 тостів; спостерігайте за довгими задачами.
• Властивості анімації: переконайтеся, що анімується лише transform/opacity.
• Обмеження видимих: кап до 3–5; згорнути решту.

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

Поширені помилки: симптом → корінна причина → виправлення

1) Toast з’являється позаду модалки

Симптом: toast в DOM, але не видно під час модалок.

Корінна причина: шкала z-index непослідовна; модалка вище toast, або toast застряг у нижчому контексті стекування.

Виправлення: перемістіть регіон toast у корінь документа через портал і визначте токени z-index. Чітко вирішіть, чи мають toasts перекривати модалки.

2) Toast обрізається на краю контейнера

Симптом: toast «обрізається», коли поруч із краєм сторінки або в обгортці макета.

Корінна причина: предок має overflow: hidden/clip або toast не справді прив’язаний до viewport.

Виправлення: рендерте toasts поза контейнером, що обрізає; за можливості приберіть overflow: hidden з предків.

3) Toast блокує кліки на сторінці

Симптом: користувач не може натиснути кнопки поруч із регіоном toast, навіть коли сам toast не перекриває кнопку.

Корінна причина: контейнер toast перехоплює pointer-events по всій області.

Виправлення: pointer-events: none на контейнері, pointer-events: auto на toast.

4) Анімації toast здаються повільними і роблять додаток «важким»

Симптом: пропущені кадри, ривки під час прокрутки, підвисання при кількох toast-ах.

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

Виправлення: анімуйте transform/opacity, зменшіть важкі ефекти, обмежте видимі toasts і уникайте вимірювань макета на кожному кадрі.

5) Новий toast з’являється «під» старим (невірний напрям стеку)

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

Корінна причина: порядок DOM і напрямок flex не відповідають семантиці розміщення.

Виправлення: для нижніх розміщень використовуйте flex-direction: column-reverse (або інвертуйте порядок DOM), щоб нові toasts з’являлися біля нижнього краю.

6) Вміст toast перекривається або стискається при переносі тексту

Симптом: довгі повідомлення перекривають кнопку закриття або непередбачувано обрізаються.

Корінна причина: абсолютне позиціонування всередині toast, фіксована висота або негнучкі колонки гріда.

Виправлення: використовуйте CSS grid з розумними колонками (іконка | контент | дії), дозволяйте контенту переноситися, уникайте фіксованих висот.

7) Зчитувач екрану оголошує кожен toast як надзвичайну подію

Симптом: допоміжні технології постійно перериваються.

Корінна причина: використання aria-live="assertive" для рутинних оновлень.

Виправлення: використовуйте polite для звичайних toasts; залишайте assertive тільки для дійсно нагальних відмов. Розгляньте обмеження частоти оголошень.

8) Toast-и дублюються при навігації

Симптом: після зміни маршруту існують кілька регіонів; toasts показуються двічі.

Корінна причина: провайдер toast монтується на кожному маршруті, а не в корені додатка; кілька #toast-root.

Виправлення: монтируйте провайдера один раз у верхньому рівні. Переконайтеся, що в HTML лише один #toast-root.

Контрольні списки / покроковий план

Чеклист для збірки: набір «випустіть без жалю»

• Регіон toast монтовано один раз в корені документа (портал).
• Регіон використовує position: fixed і інсети safe-area.
• Регіон пропускає кліки: контейнер pointer-events: none, toast auto.
• Стек використовує flex + gap; без ручних Y-офсетів.
• Розміщення контролюється одним data-placement або класом.
• Максимум видимих toast встановлено (3–5) із політикою згортання.
• Анімації використовують transform + opacity; підтримка reduced-motion.
• z-index через токени; без гігантських чисел у випадкових компонентах.
• Доступність: стратегія live-регіонів визначена; фокус не крадеться за замовчуванням.

Покроково: реалізуйте розміщення та рух без хаосу

1. Створіть регіон: один .toast-region з фіксованим позиціонуванням і padding для safe-area.
2. Реалізуйте стекування: flex column з gap; вирішіть newest-top vs newest-bottom для кожного розміщення.
3. Додайте варіанти розміщення: правила data-placement для top-right, top-left, bottom-right, bottom-center.
4. Додайте атрибути стану: data-state="entering|steady|exiting" для хук-ів анімації.
5. Підключіть анімації: keyframes з transform/opacity і override для reduced-motion.
6. Встановіть політику z-index: визначте токени і приберіть чужі значення z-index.
7. Протестуйте шторм toast-ів: відрендерте 50 тостів у деві; переконайтеся у відсутності накладень, ривків і блокування кліків.
8. Протестуйте оверлеї: відкрийте модалки, dropdown-и, тултіпи; перевірте правила шарування.
9. Протестуйте мобільні safe-area: пристрої з вирізами, ландшафт, збільшення масштабу.
10. Пройдіть перевірку доступності: клавіатурна навігація, оголошення зчитувачем екрану, налаштування руху.

Операційний чеклист: коли продукт змінює вимоги

• Якщо потрібні постійні повідомлення: направляйте їх у панель повідомлень, а не подовжуйте таймаути toast-ів.
• Якщо потрібні вбудовані дії: переконайтесь, що кнопки реальні та доступні з клавіатури; уникайте «клікабельного toast» як єдиної взаємодії.
• Якщо потрібно більше розміщень: додавайте варіанти через змінні; не форкуйте CSS під кожне розміщення.
• Якщо потрібно багатший контент: обмежте ширину, дозвольте перенос і тестуйте з локалізованими рядками.

Часті запитання

1) Чи мають toasts з’являтися над модалками чи під ними?

Вирішуйте залежно від семантики. Якщо модалка — критична взаємодія (підтвердження платежу, безпека), тримайте toasts під нею. Для неблокуючих модалів toasts зверху можуть бути допустимі. Що б ви не вибрали — зафіксуйте це в токенах z-index і не давайте командам діяти на свій розсуд.

2) Чому мій фіксований toast рухається при прокрутці всередині контейнера?

Бо він фактично не фіксований до вікна перегляду. Якщо регіон toast знаходиться всередині трансформованого предка або скрол-контейнера, fixed-позиція може поводитись як відносна до того предка. Рендерте регіон у корені документа і по можливості приберіть трансформи з предків.

3) Скільки toasts має бути видимими одночасно?

Три-п’ять. Більше перетворюється на спам UI і борг по продуктивності. Якщо у вас дійсно більше, згорніть їх у підсумок або перемістіть до панелі повідомлень.

4) Чи мають успішні toasts автозакриватися?

Зазвичай так, із коротким часом. Помилки складніші: автозакриті помилки пропускають. Якщо користувачу потрібно діяти — не використовуйте toast; використайте вбудований UI або панель з постійним станом.

5) Чи можна анімувати висоту для плавного згортання?

Можете, але це часто джерело ривків, бо тригерить layout. Якщо робите — тримайте кількість низькою, тестуйте на слабких пристроях і надавайте перевагу transform/opacity для самого toast. «Плавне» згортання, що пропускає кадри, не є плавним.

6) Чому мої toasts накладаються при переносі тексту?

Зазвичай через ручні Y-офсети або абсолютне позиціонування всередині toast. Використовуйте природну розкладку (grid/flex) і дайте висоті toast розширюватися. Для стекування використовуйте flex + gap.

7) Яке найкраще розміщення для мобільних пристроїв?

Bottom-center поширене, бо великі пальці і увага знаходяться нижче. Але це може конфліктувати з нижньою навігацією та системними жестами. Поважайте safe-area insets і тестуйте в альбомній орієнтації. Верхні розміщення зменшують конфлікти з жестами, але можуть перетинатися з адресними рядками і вирізами. Виберіть один варіант і перевірте його на пристроях.

8) Чи має toast бути клікабельним цілком?

Тільки якщо ви насправді цього хочете. Велика область цільового кліка може спричиняти випадкові переходи, особливо коли toast з’являється біля місця, де користувач вже натискає. Надавайте перевагу явним кнопкам (Відмінити, Повторити, Переглянути деталі).

9) Як запобігти дублюванню toast-ів при навігації?

Монтуйте провайдера toast один раз у корені додатка і рендерте в один кореневий елемент toast. Дублікатами часто виявляються провайдери на кожному маршруті або кілька #toast-root у шаблонах сторінок.

10) Як не допустити, щоб toasts закривали важливий UI?

По-перше: настройка pointer-events, щоб вони не блокували кліки поза самим toast-ом. По-друге: вибір розміщення, що уникає основних CTA (часто top-right на десктопі, bottom-center на мобільному). По-третє: розгляньте адаптивні зсуви, коли є нижня навігація, але не перевантажуйте рішення — тестуйте і вибирайте стабільні дефолти.

Висновок: наступні кроки, що дійсно допомагають

Якщо ваша система toast крихка, це не через те, що CSS складний. Це через те, що інтерфейс — це шаруватий світ із реальними обмеженнями: контексти стекування, оверлеї, доступність і продуктивність під навантаженням. Ставте toasts як повноцінний оверлей, а не декоративний післямова.

Зробіть наступне:

• Перенесіть регіон toast у портал кореня документа і забезпечте одне монтовання.
• Впровадьте політику токенів z-index і видаліть гігантські числа.
• Використовуйте flex + gap для стекування, обмежте видимі toasts, згорніть переповнення.
• Анімуйте через transform/opacity, додайте підтримку reduced-motion і протестуйте шторм toast-ів.
• Виправте pointer-events так, щоб регіон пропускав кліки.

Потім прогоріть план діагностики — навмисно — перш ніж продакшн зробить це за вас.