CSS Banners & Alerts

Match the pattern to the urgency and the surface. Inline status messages (the form submitted, the upload finished, the integration is connected) want the Bootstrap-style semantic alerts from demo 3 — they sit in the document flow, they map success/error/warning/info to four obvious colours, and screen readers already know how to read them when you wire `role="alert"` and `aria-live`. Long-form changelog or docs entries (deprecated API, breaking change, migration guide link) want the minimalist border-left from demo 9 — the 3px left border lets the message stack vertically inside a card without each entry needing its own colored fill, which would compete with body copy. Ephemeral confirmations (saved, copied, deleted) want the top-right toast from demo 7 — they don't interrupt the user's hand position, they auto-dismiss in 4–6 seconds, and they queue cleanly with `position: absolute` inside the wrapper. The wrong choice is using a toast for a critical error (it disappears before the user reads it) or using an inline alert for a 'copied to clipboard' (it interrupts flow for an action the user already completed).

Demo 2 wraps the announcement in `<aside role="region" aria-label="Site announcement">` so screen readers announce it as a navigation landmark, and uses `position: sticky; top: 0; z-index: 50` so it survives page scroll without leaving the document flow (which is what a `position: fixed` banner would do — and that breaks the layout because the next section starts under the banner). The dismiss button is a real `<button type="button" aria-label="Dismiss announcement">` (not a `<div onclick>`), so it's keyboard-focusable and announced as a button. Persistence is handled with `localStorage` keyed by the banner's content hash, so dismissing the v2.0 launch banner doesn't dismiss the next campaign automatically. Critical detail: do not animate the banner's `height` on dismiss — animate `max-height` + `opacity` together and remove from the DOM after the transition, so the page reflow happens once.

Demo 4 anchors a real `<dialog>`-equivalent banner to `position: absolute; bottom: 0` of its wrapper (in production: `position: fixed`) with three buttons: Accept all, Reject all, and Customize. The Reject button must be visually equal in weight to Accept — the EU Court of Justice has ruled that pre-checked or weighted-toward-accept patterns are not valid consent. The banner does not load any analytics or marketing scripts until consent fires; it only sets a `cookieConsent` value in `localStorage` and dispatches an event the rest of the app listens for. Don't conflate 'GDPR cookie banner' with 'newsletter signup' — they are legally separate consents. The visible category toggles (Essential always on, Analytics off by default, Marketing off by default) make the Customize flow meet the granular-consent test.

Demo 12 uses the CSS `@property --ba-grd-angle { syntax: '<angle>'; inherits: false; initial-value: 0deg }` declaration to make a CSS variable typed as `<angle>`, which is the only way to animate `conic-gradient(from var(--ba-grd-angle) …)` in pure CSS — without `@property`, the browser doesn't know how to interpolate the variable, so the gradient snaps instead of sweeping. The border is two layered backgrounds: an outer conic gradient and an inner solid `linear-gradient(white, white)` clipped with `background-clip: padding-box, border-box`, so the border shows the gradient and the content area stays opaque. Resize without breaking: the demo binds a ResizeObserver to the alert, so when the container width changes the gradient stops re-distribute correctly along the new perimeter. Pure-CSS-only alternative: use `mask-composite: exclude` with a SVG mask — equivalent visual, no JS, but slightly less browser support.

In a real product, demo 7's toast stack lives at `position: fixed; top: 24px; right: 24px` — it floats over the entire viewport. Inside this gallery, multiple demos render on the same page, and a `position: fixed` toast would escape its own wrapper and overlap the demo above it. The fix is `position: absolute; top: 24px; right: 24px` scoped to the `.ba-tst` wrapper (which has `position: relative` itself), so the toast is contained within the demo's stage. The toast queue, auto-dismiss timeout, swipe-to-dismiss gesture, and ARIA `aria-live="polite"` semantics are all preserved — only the positioning context changes. When you copy the code into your own project, change the wrapper class's `position: relative` back to nothing and the toast becomes viewport-fixed automatically. Same trick handles demo 4 (cookie banner) and demo 13 (Material floating card).

Every demo is wrapped in its own scoped class — `.ba-dis` (dismissible), `.ba-stk` (sticky top), `.ba-bts` (Bootstrap-style), `.ba-cok` (cookie), `.ba-frm` (form validation), `.ba-icn` (icon-aligned), `.ba-tst` (toast), `.ba-pul` (pulsing), `.ba-bdl` (border-left), `.ba-dgs` (diagonal slash), `.ba-hro` (hero), `.ba-grd` (gradient border), `.ba-mat` (Material), `.ba-twp` (text wrap). All `:root { --foo: … }` design tokens from the source mocks are re-scoped to `.ba-XX { --ba-XX-foo: … }` so they don't leak to the host page or collide with other demos. Body-level styles (background, font-family, padding) are re-applied to the wrapper. JS handlers use `data-ba-XX-*` attributes and scope queries to `root.querySelector` so multiple demos with the same alert-type label can coexist. Result: all fourteen demos render on the same gallery page without a single style or JS collision.