Why learn this?

Every webmail interface — Gmail, Outlook, Yahoo Mail — shares the same layout: a folder sidebar, a message list with sender/subject/date, and a compose overlay. This three-panel pattern is the most common data-display UI on the web. Building it teaches CSS Grid for layout, semantic HTML5 landmarks (<nav>, <main>, <table>), and the overlay pattern used across dashboards and web apps.

Design decisions & tradeoffs

CSS Grid for layout. The page uses grid-template-columns: 200px 1fr for the sidebar+content split. The alternative — float-based layouts or flexbox — both work but Grid handles the fixed-sidebar/flexible-content pattern most cleanly. The 200px sidebar is wide enough for folder names with unread counts without wasting space.

Table for message list. Email messages are tabular data (From, Subject, Date). A <table> with table-layout: fixed is semantically correct and handles column alignment natively — something CSS flexbox rows cannot do without manual width coordination.

Compose as overlay vs separate page. The compose form is a <section> within the same page, toggled by a CSS class. This mirrors how real webmail works — the inbox stays visible behind the compose view. A separate compose page would require URL routing and back-button handling.

Browser compatibility

• CSS Grid: Supported in all browsers since 2020. No prefix needed.
• table-layout: fixed: Supported since IE 5. The most universally compatible layout property.
• hidden attribute: HTML5 global. Supported since IE 11.

Accessibility details

• Sidebar navigation semantics. The folder sidebar uses <div> elements with click handlers. Use <nav aria-label="Folders"> with <button> elements for proper keyboard accessibility and screen reader announcements.
• Compose overlay focus management. When the compose overlay opens, focus should move to the first input (To field). When it closes, focus should return to the Compose button. Without focus management, keyboard users are stranded.
• Table semantics for message list. The message list is a <table> with <thead> and <tbody> — semantically correct. Each row is interactive (clickable), but screen readers don't announce rows as actionable. Add role="button" or tabindex="0" to rows for accessibility.
• Compose form label associations. Each input has an associated <label for="...">. This is WCAG 3.3.2 compliance — clicking the label focuses the input, and screen readers announce the label on focus.
• Overlay backdrop. The compose overlay uses a semi-transparent backdrop that is purely visual — no aria-hidden on the background content. When the overlay is open, set aria-hidden="true" on the main content to prevent screen readers from accessing background elements.

Common pitfalls

• Missing table-layout: fixed. Without it, column widths shift as content changes because the browser auto-sizes.
• Forgetting event.preventDefault() on form submit. Without it, the browser reloads the page.
• Storing the compose form inside the sidebar. It should be an overlay, not embedded.

Key concepts

• display: grid — Two-column sidebar + content layout. Foundation of dashboard UIs
• <table> with table-layout: fixed — Structured message list with aligned columns
• <form> — Semantic compose form. No JavaScript required for basic structure
• data-folder — Custom HTML data attributes. Carries folder metadata in the DOM
• hidden class — CSS-based visibility toggle for the compose overlay

Next up

Step 2 adds the iconic Hotmail aesthetic: a CSS-only plaid checkered background, blue gradient header, read/unread message styling, and folder sidebar active states.

Why learn this?

The 1996 Hotmail aesthetic is iconic: a tiled plaid/checkered background, blue gradient header, and clean table layout. This step teaches CSS-only background patterns using repeating-linear-gradient — a technique that creates textile-like patterns without images. You also learn read/unread styling with font-weight and box-shadow, table row hover effects, and sticky headers.

Design decisions & tradeoffs

CSS-only plaid vs image. Two repeating-linear-gradient layers (horizontal + vertical stripes) create the plaid pattern. Zero HTTP requests, resolution-independent, infinitely customizable. The tradeoff is minimal GPU compositing cost from the gradient rendering.

Read/unread with bold text. Unread messages get font-weight: 700 plus a teal left-border via box-shadow. This works universally — no color perception dependency, no language barriers.

Gradient header with blue accent. The header uses linear-gradient(135deg, #0066CC, #004d99) — a diagonal blue gradient that matches Hotmail's 1996 brand. White text on the gradient provides clear contrast. The alternative — a flat blue header — would be simpler but lacks the depth gradient provides.

Table row hover for feedback. Rows highlight on hover with a subtle background shift. This provides interactive feedback without requiring click-to-select — a pattern standard in every data table since.

Browser compatibility

• repeating-linear-gradient(): Supported since Chrome 26, Firefox 16, Safari 6.1, IE 10. The plaid background works in all modern browsers. IE 9 shows the solid fallback color.
• linear-gradient(): Supported since Chrome 26, Firefox 16, Safari 6.1, IE 10. Used for the header gradient. Falls back to flat color in IE 9.
• box-shadow: Supported since Chrome 4, Firefox 3.5, Safari 5, IE 9. Used for the unread indicator. Falls back silently in IE 8.
• position: sticky: Supported since Chrome 56, Firefox 59, Safari 13. Used for sticky table headers. In older browsers, headers scroll with content — functional but less usable.
• background-blend-mode: multiply: Supported since Chrome 35, Firefox 30, Safari 7.1. Blends the two gradient layers for the plaid effect. Without it, the two gradient layers overlay visibly — still readable but less fabric-like.

Accessibility details

• Read/unread distinction with non-color cues. The unread indicator uses both font-weight: 700 and a teal box-shadow border — a dual-signal approach that doesn't rely solely on color. Users with color vision deficiency still perceive the bold text as "important."
• Table row hover effect. The hover effect is purely decorative — it does not convey information. However, if it's the only way to identify clickable rows, keyboard users miss the signal. Ensure rows are visually identifiable as interactive without hover.
• Background pattern contrast. The plaid pattern uses very low opacity (rgba(0,212,170,0.02)) — subtle enough to not interfere with text readability. The solid #0d0d12 background provides the base contrast. Text is white on this dark background — ~14:1 contrast ratio.
• Sticky header visual separation. The sticky table header uses a background color to separate from scrolling content. Ensure the header background is sufficiently opaque to prevent text from showing through when scrolling.
• Focus indicators on interactive elements. The folders, compose button, and table rows lack explicit focus-visible styles. Tab through the page and add :focus-visible styles matching the hover state for keyboard accessibility.

Common pitfalls

• Wrong gradient angle. 0deg = horizontal stripes, 90deg = vertical. You need both for plaid.
• Missing fallback background. Always set a solid background-color before the gradient.
• Stripe width too large. Stripes wider than 2px look like a grid, not fabric.

Key concepts

• repeating-linear-gradient() — Creates tiled patterns. Two layers (H+V) make plaid
• background-blend-mode: multiply — Blends gradient layers for the plaid effect
• font-weight: 700 vs 400 — Read/unread distinction
• position: sticky — Sticky table header that stays visible during scroll
• linear-gradient(135deg, ...) — Diagonal gradient for the header
• box-shadow: inset — Inset shadow creates the left-border unread indicator

Next up

Step 3 adds JavaScript: compose toggle, send message, click-to-mark-as-read, and folder switching.

Why learn this?

Compose, send, read, and folder-switch are the core CRUD operations of any messaging system. This step adds client-side JavaScript to make the static layout functional. You learn the compose-view toggle pattern, form submission with preventDefault(), click-to-mark-as-read via event delegation, and folder switching with data attributes — four patterns that appear in every interactive web app.

Design decisions & tradeoffs

Event delegation. A single click listener on <tbody> catches all row clicks via event bubbling. The alternative — a listener on each <tr> — creates 10+ listeners that need re-attaching after every render. One delegated listener is O(1).

Data array + render function. Messages live in a JavaScript array. renderMessages() rebuilds the DOM from the array. This unidirectional data flow (state → render) is the same pattern React, Vue, and Svelte use.

Class toggle for compose overlay. The compose form uses classList.toggle('hidden') for show/hide. The alternative — setting style.display directly — works but mixes presentation logic into JavaScript. CSS classes keep styling concerns in CSS where they belong.

data-folder for routing. Each folder button carries a data-folder attribute. The switch function reads this attribute to determine which messages to display. This is the declarative routing pattern — the HTML declares the available routes, and JS reads them. Adding a new folder requires only HTML (no JS changes).

Browser compatibility

• classList.toggle(): Supported since Chrome 8, Firefox 3.6, Safari 5.1. Used for compose visibility and folder active states.
• event.preventDefault(): Supported universally. Form submission interception works in all browsers.
• Array.filter(): Supported since Chrome 1, Firefox 1.5, Safari 3. Used for folder filtering.
• HTMLElement.dataset: Supported since Chrome 7, Firefox 6, Safari 5.1. Reads data-folder values.
• Element.closest(): Supported since Chrome 41, Firefox 35, Safari 6. Used for event delegation on table rows.
• textContent: Supported universally. Used for setting dynamic content safely (no XSS vector like innerHTML).

Accessibility details

• Compose toggle as button. The Compose button should be a native <button> — keyboard accessible (Enter/Space to activate) and announced by screen readers. If it's a <div> or <span> with onclick, it's not keyboard accessible without tabindex="0" and role="button".
• Focus management on compose open/close. When compose opens, focus should move to the To field. When it closes (cancel or send), focus should return to the Compose button. Without this, keyboard users lose their place on the page.
• Mark-as-read event delegation. The click handler on <tbody> uses e.target.closest('tr') — this catches clicks on <td> elements and finds the parent row. Works for mouse clicks. Keyboard users navigating row-by-row with Tab won't trigger this — add a keydown handler for Enter/Space.
• Folder active state announcement. The active folder is visually indicated by a CSS class. Screen readers don't announce this state change. Use aria-current="page" on the active folder button, or aria-pressed="true" depending on the role.
• Dynamic content not announced. When renderMessages() replaces the table body content, screen readers don't announce the change. Add aria-live="polite" to the message list container so updated content is announced.

Common pitfalls

• Missing preventDefault() on form submit. The browser reloads the page. Always call e.preventDefault() first.
• Mutating the original array. filter() returns a new array. But push() and splice() mutate. Keep a single source-of-truth array.
• innerHTML vs textContent for user data. Using innerHTML to render message subjects opens XSS vectors. Use textContent or createTextNode() when rendering user-supplied content.

Key concepts

• event delegation — Single listener on parent. Catches all child events via bubbling
• data-folder — Custom data attribute for folder routing
• Array.filter() + render() — Filter data, rebuild the view
• classList.toggle() — Show/hide compose overlay
• event.preventDefault() — Prevent page reload on form submit
• Array.map() + join('') — Transform array to HTML string

Next up

Step 4 adds search, contacts, and localStorage persistence — making the demo a fully usable webmail client.

Why learn this?

A webmail client that loses all messages on refresh is useless. This step adds the three features that turn a demo into a real app: full-text search (filter messages by any field), a contact list with CRUD, and localStorage persistence that survives page reloads. These patterns — search-by-multiple-fields, contact CRUD, serialize/save/load — appear in every application that stores user data.

Design decisions & tradeoffs

localStorage vs IndexedDB. localStorage is synchronous, simple, and stores key-value pairs as strings. For a demo with under 100 messages, its simplicity wins over IndexedDB's async API and 5MB limit. For production, use IndexedDB — it's non-blocking and has no practical size cap.

Case-insensitive includes for search. String.includes() after lowercasing both query and data. The alternative — regex — supports patterns but adds complexity. Include-based search is good enough: "proj" matches "Project update."

Contact list as sidebar section vs popup. Contacts are rendered as a collapsible section in the sidebar. The alternative — a popup or separate view — would need more navigation state. The sidebar approach keeps contacts accessible without hiding the message list.

Persistent state across refreshes. loadData() runs on page load to restore messages and contacts from localStorage. This makes the demo feel like a real app — data survives browser refreshes and even tab closures (within the same origin).

Browser compatibility

• localStorage.setItem/getItem: Supported since IE 8, Chrome 4, Firefox 3.5, Safari 4. Universal support. 5MB limit per origin.
• JSON.stringify/parse: Supported since IE 8, Chrome 1, Firefox 3, Safari 4. Used for object serialization.
• String.prototype.includes(): Supported since Chrome 41, Firefox 40, Safari 9. Used for search matching. Falls back to indexOf() !== -1 in IE 11.
• Array.prototype.some(): Supported since Chrome 1, Firefox 1.5, Safari 3. Used for multi-field search.
• textContent: Supported universally. Used for safe content rendering.

Accessibility details

• Search input needs a label. The search input has no <label>. Add <label for="search" class="sr-only">Search messages</label> for screen reader support. Placeholder text is not a substitute — it disappears on input.
• Search results not announced. When the search filters messages, the updated list is not announced to screen readers. Add aria-live="polite" to the message list container.
• Contact list items as actionable. Contact items show an email address and are clickable (to open compose with that recipient). If they're <div> or <span> elements, they need role="button", tabindex="0", and keyboard event handlers. Use <button> elements for proper semantics.
• localStorage notice. Users in private browsing modes may get errors when trying to write to localStorage. The app should handle QuotaExceededError and SecurityError exceptions gracefully, falling back to in-memory operation.
• Dynamic DOM updates. Both search and contact CRUD modify the DOM dynamically. Ensure all dynamic content is keyboard accessible and screen-reader friendly.

Common pitfalls

• Storing Date objects in localStorage. They become ISO strings. Always reconstruct with new Date() after loading.
• Forgetting to save on every mutation. Use a single saveData() function called after every add/delete/edit.
• localStorage quota exceeded. Always wrap setItem in a try/catch. Private browsing and full storage will throw errors.

Key concepts

• localStorage.setItem/getItem — Persist data across page reloads
• JSON.stringify/parse — Serialize objects to strings for storage
• String.includes() — Case-insensitive field matching for search
• Array.some() — OR-based multi-field search
• try/catch for localStorage — Handle quota and security errors gracefully
• textContent vs innerHTML — Safe content rendering prevents XSS

Next up

Your Hotmail Clone is complete! You've built a functional webmail client with compose, send, folder switching, search, contacts, and data persistence. View the live demo →