15 CSS Chat Bubbles

Three techniques, and the right one depends on what the bubble sits on. The border trick is the classic: a zero-size ::after with transparent borders on three sides and a coloured border on the fourth produces a triangle — border: 9px solid transparent; border-inline-end-color: var(--bubble-bg) pinned to the bubble's edge with position: absolute. It is universally supported and costs nothing, but the triangle is flat, so it cannot follow a gradient or a border. The second option is a rotated square: a small element with transform: rotate(45deg) tucked half-behind the bubble, which inherits the bubble's background including a gradient, and can carry the same border for outlined styles. The third is clip-path: polygon() on the bubble itself, cutting the tail out of one shape — elegant, but remember that clip-path also clips the element's own pseudo-elements, so any decorative extras have to move to a wrapper. Two details that separate a convincing tail from an obvious one: the tail should sit flush with the bubble's bottom edge for a chat log rather than centred, and only the last bubble in a run gets one — repeating the tail on every grouped message is what makes hand-built chat UIs look wrong.

Both are recognisable from three properties, and getting them slightly wrong is more noticeable than not attempting them. iMessage: outgoing bubbles use a blue gradient (roughly #0b93f6 to #0a7cff) with white text, incoming use #e9e9eb with near-black text, both at a border radius around 18px on a ~17px font. The tail is a rounded shape rather than a hard triangle, which is why a plain border triangle reads as "nearly iMessage". WhatsApp Web: outgoing is the pale green #d9fdd3 on a patterned background, incoming is white, radius is tighter at about 7.5px, and the timestamp plus delivery ticks sit inline at the bottom-right inside the bubble, floated so the text wraps around them. That inline metadata is the detail most recreations miss. In both apps, consecutive messages from the same sender group with a small gap and only the final bubble keeps its tail. Demos 02 and 08 implement both, and the copy is generic sample text rather than anything resembling either company's branding.

Three dots with staggered animation delays, and the whole thing is about eight lines. Each dot animates opacity or translate on a loop, offset by roughly 160ms: .dot:nth-child(2) { animation-delay: .16s } .dot:nth-child(3) { animation-delay: .32s }. Animate transform and opacity only — animating height or margin forces layout on every frame for what is a purely decorative loop. The part people skip is the accessibility. A typing indicator is a live status, so it belongs in a region with aria-live="polite" and a visually-hidden text equivalent like "Priya is typing" — three animated dots convey nothing to a screen reader. Equally important, it must stop under prefers-reduced-motion: reduce, and the honest fallback is the static text rather than three frozen dots, which look like a rendering bug. Finally, do not leave it running indefinitely: an indicator that never resolves is worse than none, so clear it on a timeout as well as on message arrival.

A chat log is a list of messages, so it should be an <ol> — ordered, because sequence is meaningful — with each message an <li>. Inside, the sender and timestamp belong in structured markup rather than floating divs: an <article> per message with a <header> carrying the sender name and a real <time datetime="2026-08-12T14:08"> is the shape that survives both screen readers and copy-paste. Do not rely on left/right alignment alone to convey who spoke — that is visual-only information, so each message needs the sender's name in the accessible name even when it is visually hidden for grouped runs. For a live conversation, wrap the log in aria-live="polite" so new messages are announced, but scope it carefully: marking the entire scrolling history as live means every re-render re-announces everything. The usual approach is a live region containing only the newest message, with the historical log outside it.

The layout is straightforward — a flex column with the header and composer fixed and the message list taking the remaining space — but two behaviours are where chat UIs usually break. First, new messages should pin to the bottom, and the modern way is flex-direction: column-reverse on the scroll container with the messages in reverse order, which makes the browser anchor scrolling to the bottom natively. Alternatively, keep normal order and use overflow-anchor, or set scrollTop = scrollHeight after append. Second, do not force-scroll when the user has deliberately scrolled up to read history — check whether they are near the bottom first, and if not, show a "new messages" affordance instead of yanking them down. On mobile, the composer needs padding-block-end: env(safe-area-inset-bottom) or the home indicator overlaps it, and the container should use 100dvh rather than 100vh so the collapsing browser chrome does not leave a gap. Demo 11 implements the full screen.

The waveform is a row of bars whose heights come from real amplitude data — an array of values between 0 and 1, one per bar, written into each bar as a custom property and read by block-size: calc(8% + var(--h) * 92%). That keeps all the layout in CSS and the data in one small array. Progress is the interesting part: rather than redrawing bars as playback advances, layer a second identical waveform in the accent colour and clip it with clip-path: inset(0 calc(100% - var(--p)) 0 0), so a single custom property drives the fill. One trap this collection hit directly: do not give the bars a min-width. With 44 bars at 3px plus gaps, that is a 218px hard floor, and a chat bubble on a 320px phone has roughly 150-190px available — the row refuses to shrink and pushes the page sideways. Let the bars compress with flex: 1 1 0; min-inline-size: 0 instead. For accessibility, the waveform is decorative and should be aria-hidden; the real control is a labelled play button plus a native <input type="range"> for scrubbing.

The bubbles themselves are simple; the accessibility work is in the conversation around them. Colour contrast is the first risk — the pale green and light grey that messaging apps use sit close to the 4.5:1 floor, so any custom palette needs checking rather than eyeballing, and a white-on-light-blue outgoing bubble frequently fails. Sender identity must not depend on alignment or colour alone, since neither is available to a screen reader user: the name belongs in the markup even when visually hidden in grouped runs. Timestamps use <time datetime> so the machine-readable value is unambiguous regardless of how it is formatted visually. Every interactive element — play buttons, reaction triggers, expand toggles — is a real <button> with a visible :focus-visible ring at 2px minimum and a 44 by 44 CSS pixel hit target. Animated indicators respect prefers-reduced-motion and fall back to text rather than freezing. And any auto-scrolling log needs to be interruptible, since content that moves under a reader is a WCAG 2.2.2 problem as much as a usability one.

The CSS ports unchanged; what changes is that a chat log is data-driven, so the natural shape is a <Message> component taking sender, body, timestamp and a variant, rendered from an array. Two structural notes matter more than the syntax. Message grouping — only the last bubble in a run gets a tail, and repeated senders collapse their header — is derived state, so compute it while mapping (compare each message's sender to the previous one) rather than storing a isLastInGroup flag that can drift out of sync. And auto-scroll belongs in a layout effect rather than a normal one: React's useLayoutEffect runs before paint, so the jump to the bottom happens without a visible flash, whereas useEffect shows one frame at the old position. Vue's nextTick and Svelte's afterUpdate serve the same purpose. In the Next.js App Router the log itself can render on the server while only the composer and live updates need 'use client'. For Tailwind, demo 04 is already written as utilities, with the tail kept as a small piece of real CSS since a pseudo-element triangle has no clean utility equivalent.