Why learn this?

Every dating platform — from Match.com to Tinder to Hinge — shares the same fundamental HTML patterns: a profile-centric header with search and notifications, a browse grid or stack of potential matches, detailed profile cards with photos and bio, and a messaging interface for conversations. Match.com's original desktop design is particularly instructive because it blends profile browsing (with compatibility scores, shared interests, and last active timestamps) alongside a structured messaging system — all centered around the user's own profile as the anchor point. Building a Match.com clone teaches the profile card pattern, the browse-then-connect UX flow, compatibility scoring display, and the messaging interface that powers every dating app on the web.

Design decisions & tradeoffs

Profile-first header with notifications. The Match.com header centers the user's profile photo and name as the primary element, with search and notification icons as secondary actions. This reflects Match's philosophy that your identity is the foundation of the experience — unlike eBay (where search dominates) or Amazon (where cart dominates), dating apps put your profile front and center. The red header (#e0134a) with white text matches Match.com's signature brand color, instantly recognizable across the dating industry.

Browse grid vs card stack. Match.com originally used a grid of profile cards (similar to eBay's item grid), not the swipeable card stack that Tinder popularized. The grid shows 6-12 profiles at once with photos, names, ages, distances, and compatibility scores. This design lets users compare multiple profiles simultaneously — better for deliberate, personality-focused dating than the rapid-fire swipe model. The alternative — a full-screen card stack — would favor quantity over quality and lose the comparison context that makes Match.com's browsing feel intentional.

Profile card structure: photo, info, compatibility. Each profile card is an <article> element with three sections: a primary photo (<figure> <img> </figure>), profile details (name, age, location, last active), and compatibility indicators (shared interests as tags, match percentage). This structured card pattern — photo dominant, details below, compatibility badges — is the universal dating card format used by every platform from Match to OkCupid to Bumble. The <article> element provides semantic meaning (each card is a self-contained profile) and screen reader navigation via landmarks.

Compatibility score as structured data. Match percentage is wrapped in a <span class=\"match-pct\"> with a data-score attribute for JavaScript consumption. The visible text shows a percentage (e.g., "87% Match") while the data-score attribute stores the raw number for filtering and sorting. The alternative — storing the score only as visible text — would make it impossible to sort or filter profiles by compatibility without parsing natural language. The data-score attribute is the hook for the JavaScript matching algorithm.

Interest tags as semantic list. Shared interests are displayed as <ul class=\"interest-tags\"> with <li> items — not as comma-separated text. This provides proper semantics (a list of interests), enables styling each tag independently (colored badges), and allows screen readers to announce each interest separately. The alternative — a text string like "hiking, coffee, travel" — loses the tag-level interaction (clicking a tag to find more people with that interest) and the visual rhythm that makes profile cards scannable.

Chat as a separate route. Messaging is at /chat/ rather than embedded in the browse page. This separation follows Match.com's original architecture — browsing and messaging are distinct mental modes. The browse page is about discovery (evaluating potential matches), while the chat page is about connection (deepening existing matches). Combining them would create cognitive overload and make both experiences worse. The <aside> element wraps the recent matches sidebar, providing a semantic landmark for "related but secondary content."

Browser compatibility

• CSS Grid (grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))): Supported since Chrome 57, Firefox 52, Safari 10.3. The auto-fill pattern creates responsive columns without media queries. Falls back to a single column in older browsers.
• <figure> and <figcaption>: Supported since Chrome 8, Firefox 4, Safari 5.1. Used for profile photos with optional captions. IE 9+ supports both elements.
• <article> element: Supported since Chrome 4, Firefox 3.5, Safari 4. Semantic landmark for self-contained profiles. Older browsers treat it as a generic <div> — no breakage.
• object-fit: cover on profile photos: Supported since Chrome 31, Firefox 36, Safari 7.1. Used to crop profile photos to uniform aspect ratio. In older browsers, images stretch to fill the container.
• max-width with auto margins: Supported universally. The .container centering pattern works in all browsers including IE 5.5+.
• <output> element for compatibility score: Supported since Chrome 10, Firefox 22, Safari 5.1. Used to display the calculated match percentage. IE does not support it — falls back to inline text.

Accessibility details

• Heading hierarchy. The page uses a single <h1> (the "Match" brand) inside the header, <h2> for section titles ("Browse Singles"), and <h3> for each profile card's name. This creates a clean outline: Platform → Section → Individual Profile. The profile card titles are <h3> links — screen reader users navigate by heading to jump between profiles.
• Profile card <article> landmarks. Each profile is an <article> with aria-labelledby pointing to the profile name. Screen readers can navigate between articles using landmark navigation (Rotor on iOS, landmarks menu on desktop).
• Image alt text. Profile photos have descriptive alt text generated from the profile name and context (e.g., "Photo of Sarah, 28, from Portland"). This is critical for screen reader users who rely on alt text to understand the profile. Avoid generic alt text like "Profile photo."
• Compatibility score accessibility. The match percentage uses role="meter" with aria-valuenow, aria-valuemin="0", and aria-valuemax="100". This announces the score as a progress meter to screen readers — "87% match" becomes "meter, 87 percent."
• Interest tag list semantics. Interest tags are an unordered list (<ul>) — screen readers announce "list of 5 items" and let users navigate between tags. The visual presentation (colored badges) is purely CSS — the underlying HTML is a semantic list.
• Color contrast. The Match red header (#e0134a) with white text is ~5.8:1 contrast — exceeds WCAG AA. Profile names in dark text (#1a1a2e) on white cards is ~15:1 — exceeds AAA. Match percentage in red on white is ~5.8:1 — passes AA for normal text. Interest tags in gray on light backgrounds use sufficient contrast for readability.

Common pitfalls

• Profile photo aspect ratio. Without fixed aspect ratio, photos of varying sizes break the grid alignment. Use aspect-ratio: 3/4 or object-fit: cover on a container with fixed height to ensure uniform cards. The .profile-photo container should have height: 320px and overflow: hidden as a fallback.
• Compatibility score without data attribute. If the match percentage is only in visible text, JavaScript can't sort or filter by score without parsing. Always store the raw score in a data-score attribute for programmatic access.
• Missing aria-label on action buttons. The "Like", "Pass", and "Message" buttons need aria-label attributes when they use icons only. Screen readers announce the button's accessible name, not its visual content.
• Chat messages without <time> elements. "2 hours ago" is ambiguous — does it mean 2 hours from now or 2 hours since the message was sent? Always include a specific timestamp (<time datetime="2026-07-23T14:30:00Z">) alongside relative display.
• Profile card click target. If only the photo is clickable but the entire card looks like a link, users will click the text and nothing happens. Make the entire <article> a click target using a wrapping <a> or JavaScript click handler on the card.

Key concepts

• grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)) — Responsive auto-fill grid for profile cards
• <article> — Self-contained profile landmark. Each card is a complete, independent profile
• <figure> <img> </figure> — Semantic image container for profile photos
• data-score attribute — Machine-readable compatibility score for JS filtering/sorting
• object-fit: cover — Crop photos to fill container. Prevents distortion in uniform grid
• <output> — Dynamic calculation result. Shows computed match percentage
• role="meter" aria-valuenow — Accessible progress indicator for compatibility scores

Next up

Step 2 adds full styling with Match's red theme, profile card hover effects, photo carousel indicators, compatibility score rings, and responsive grid refinements.

Why learn this?

dating platforms live or die by their visual design — the profile card is the most important UI element in any dating app, and its styling determines whether users feel attracted to the experience or repelled by it. Match.com's signature red theme (#e0134a) communicates warmth and passion, while the clean white cards with subtle shadows create a sense of premium quality. The styling teaches CSS Grid for responsive profile layouts, CSS custom properties for theming, card hover effects that create depth, and the photo-to-info visual hierarchy that every dating app uses.

Design decisions & tradeoffs

Match red as primary accent. The --accent: #e0134a color drives every interactive element: the header, like buttons, match percentage badges, and notification dots. This creates visual consistency — users instantly know what's tappable. The alternative — using multiple accent colors — would create visual noise and dilute the brand identity. Match.com's single-color approach is the same pattern used by Tinder (red), Bumble (yellow), and Hinge (white/red).

Card elevation on hover. Profile cards lift with transform: translateY(-4px) and gain a deeper shadow on hover. This creates a tactile feel — the card "peels off" the background, signaling it's interactive. The shadow progression from 0 2px 8px rgba(0,0,0,0.08) (resting) to 0 8px 24px rgba(0,0,0,0.15) (hovered) creates depth without overwhelming the layout. The alternative — no hover effect — would make cards feel flat and unresponsive.

Photo-first visual hierarchy. The profile photo takes 60% of the card height, with info and actions below. This follows the dating app convention — photos are the primary decision factor. The aspect-ratio: 3/4 on photos creates a portrait orientation that matches how people naturally photograph themselves. The alternative — square photos — would waste vertical space and make faces smaller.

Match score as a colored badge. The match percentage uses a gradient background from green (high match) to yellow (medium) to orange (low), creating an instant visual signal. The data-score attribute drives the color via CSS: scores above 90% get green, 70-90% get blue, below 70% get gray. This traffic-light pattern is universally understood — green means go, gray means maybe.

Action buttons as a bottom bar. The like/pass/super-like buttons are fixed at the bottom of each card, always visible. This creates a consistent interaction pattern — users don't need to scroll to take action. The red heart for "Like" is the dominant button (largest, most prominent), the gray "Pass" is secondary, and the gold "Super Like" is tertiary. This hierarchy guides users toward the positive action (liking) while making negative action (passing) available but not dominant.

Key CSS concepts

• CSS custom properties — --accent, --bg-card, --border for consistent theming
• grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)) — Responsive auto-fill for profile cards
• aspect-ratio: 3/4 — Portrait orientation for profile photos
• object-fit: cover — Crop photos to fill container without distortion
• transform: translateY() + box-shadow — Card lift hover effect
• linear-gradient() — Match score badge coloring based on score value
• position: sticky — Filter bar sticks below header on scroll
• flex + gap — Action button layout with consistent spacing

Common pitfalls

• Card border-radius inconsistency. Photo container and card should share the same border-radius (12px) or the photo will overflow on rounded corners. Use overflow: hidden on the photo container.
• Hover effect on touch devices. :hover doesn't work reliably on mobile. Use @media (hover: hover) to apply hover effects only on devices that support it, preventing "sticky hover" on touch.
• Z-index stacking with header. The sticky header must have z-index: 100 to stay above profile cards. Cards shouldn't have explicit z-index unless they're in a modal or overlay state.
• Photo loading layout shift. Without aspect-ratio on the photo container, images load and push content down (CLS). Set aspect-ratio: 3/4 on the container before the image loads.
• Action button touch targets. Like/pass buttons must be at least 44x44px for mobile touch targets (WCAG 2.5.5). Use min-width: 44px; min-height: 44px on the button containers.

Why learn this?

The interaction layer is where a dating app becomes alive — static profile cards become a dynamic experience when users can like, pass, super-like, and filter. Match.com's JavaScript handles profile state management (liked/passed/super-liked), filter persistence (storing preferences in localStorage), and the compatibility algorithm that recalculates match scores based on shared interests. This teaches DOM manipulation for profile actions, localStorage for user state, event delegation for dynamic card grids, and the filtering pattern that every dating app uses.

Design decisions & tradeoffs

localStorage for profile state. All liked/passed/super-liked profiles are stored in localStorage under a single JSON object. This persists across page reloads without a backend — users don't lose their browsing history when they close the tab. The alternative — storing in JavaScript variables — would reset on every page load, forcing users to re-browse profiles they already evaluated.

Event delegation for card actions. Instead of attaching click handlers to each button individually, a single event listener on the .profile-grid handles all button clicks using event.target.closest(). This works for dynamically added cards (infinite scroll) without re-binding handlers. The alternative — individual handlers on each button — breaks when cards are added or removed from the DOM.

Filter by match score. The filter bar ("Discover", "Likes", "Matches") uses a data-filter attribute to select which profiles to show. "Discover" shows all profiles, "Likes" shows only liked profiles, "Matches" shows mutual likes. The filter state is stored in a variable and re-applied when the user switches tabs. The alternative — separate pages for each filter — would require full page reloads and lose the smooth transition feel.

Compatibility algorithm. The match score is calculated by counting shared interests between the user's profile and each candidate profile. More shared interests = higher score. This is a simplified version of Match.com's actual algorithm (which uses personality tests, preferences, and behavioral data), but it teaches the core concept: compatibility is a function of shared attributes. The algorithm runs on page load and caches results in localStorage.

Visual feedback on actions. When a user clicks "Like", the card briefly flashes green and slides out. When they click "Pass", it fades to gray. This immediate visual feedback confirms the action was registered — users don't wonder "did it work?" The animation uses transition on opacity and transform for smooth 60fps performance.

Key concepts

• localStorage.setItem('key', JSON.stringify(data)) — Persist user state across reloads
• event.target.closest('.selector') — Event delegation for dynamic elements
• Array.filter() — Filter profiles by match score or like status
• element.classList.add/remove('class') — Toggle visual states (liked, passed)
• element.style.transition — Animate card actions (slide, fade)
• data-* attributes — Store match scores and profile IDs in the DOM
• JSON.parse/stringify — Serialize profile state for localStorage

Common pitfalls

• localStorage quota exceeded. localStorage has a 5MB limit per origin. If you store too many profiles with large photo URLs, you'll hit the quota. Keep profile data minimal (ID, name, score, interests — not full photo URLs).
• Stale localStorage after profile updates. If you update the user's interests in one tab, other tabs still see the old data. Use the storage event to sync state across tabs: window.addEventListener('storage', handler).
• Double-tap on mobile. On mobile, a "tap" can trigger both click and touchend events. Use pointer-events or check event.pointerType to avoid double-triggering like/pass actions.
• Animating removed elements. If you animate a card out (opacity: 0, transform: translateY(-20px)) and then remove it from the DOM immediately, the animation won't play. Use setTimeout() to delay DOM removal until the transition completes.
• Filter state lost on navigation. If the filter state is stored in a local variable, navigating away and back resets it. Persist the active filter in localStorage alongside the profile data.

Why learn this?

Messaging is where dating apps convert matches into connections — the browse experience is about discovery, but the chat experience is about depth. Match.com pioneered the structured messaging system with conversation threads, read receipts, typing indicators, and message reactions. Building a chat system teaches real-time state management, message persistence in localStorage, the chat bubble layout pattern (sender vs receiver alignment), and the typing indicator animation that signals "someone is writing." This is the same pattern used by every messaging platform from iMessage to WhatsApp to Slack.

Design decisions & tradeoffs

Chat bubbles with sender/receiver alignment. Messages from "you" align right with a colored background, messages from "them" align left with a neutral background. This visual distinction is universal — every chat app from iMessage (blue/gray) to WhatsApp (green/white) uses it. The alternative — all messages on the same side — would make it impossible to distinguish who said what without reading names.

Typing indicator animation. The three-dot bouncing animation signals "the other person is typing." This manages expectations — users know a response is coming instead of wondering if the message was seen. The animation uses CSS @keyframes with staggered delays on each dot. The alternative — no indicator — would make conversations feel one-sided and reduce response rates.

Message timestamps as relative time. Messages show "2h ago", "Yesterday", "Jul 20" — relative timestamps that update as time passes. This is more human-readable than raw timestamps ("2026-07-23T14:30:00Z") but includes the raw timestamp in a <time> element for accessibility and machine parsing. The alternative — always showing raw timestamps — would make the chat feel clinical and hard to scan.

Match header in chat view. The chat header shows the matched profile's photo, name, and compatibility score — reminding users why they're talking. This context is critical in dating apps where users may match with dozens of people. The header also includes a "Back" button to return to the browse view. The alternative — a minimal header with just the name — would lose the visual connection between the chat and the profile.

Message input with send button. The input bar has a text field and a send button (not just Enter key). This is more accessible — screen reader users can find the button, and mobile users get a clear tap target. The send button is disabled when the input is empty, preventing blank messages. The alternative — Enter-only sending — would be invisible to assistive technology users.

Key concepts

• CSS flexbox — Chat bubble alignment (sender right, receiver left)
• @keyframes — Typing indicator bounce animation
• localStorage — Message persistence across page reloads
• element.scrollIntoView() — Auto-scroll to latest message
• <time datetime="ISO"> — Machine-readable timestamps with relative display
• disabled attribute — Prevent sending empty messages
• event delegation — Handle clicks on dynamically rendered message bubbles

Common pitfalls

• Auto-scroll on new messages. If the user has scrolled up to read history, a new message shouldn't force-scroll to the bottom. Check if scrollTop + clientHeight === scrollHeight before auto-scrolling.
• Message ordering in localStorage. JSON arrays preserve order, but if you sort messages by timestamp, ensure the sort is stable (same timestamp = preserve insertion order). Use Array.sort() with a tiebreaker on message ID.
• Chat header photo aspect ratio. The profile photo in the chat header must be aspect-ratio: 1/1 with object-fit: cover to prevent stretching from square to landscape.
• Input field focus on mobile. On iOS, the virtual keyboard pushes the input field up. Use position: fixed on the input bar and padding-bottom on the chat body to prevent the keyboard from covering the input.
• Empty state for new matches. When a user matches with someone but hasn't sent a message yet, show a prompt ("Send a message to start the conversation") instead of an empty chat. This reduces friction for first messages.