20 CSS Blog Layouts

The single highest-leverage decision in a blog layout is the measure — the width of the reading column. Aim for 60-75 characters per line, which in CSS is simply max-inline-size: 65ch. The ch unit is the width of the digit zero in the current font, so it tracks your typeface rather than guessing a pixel value. Below about 45 characters the eye returns too often and rhythm breaks; above roughly 85 it loses the start of the next line. Pair it with a line height around 1.6-1.7 for body copy, tightening toward 1.2 for large headings, since generous leading helps at small sizes and looks slack at display sizes. For fluid sizing use clamp() rather than breakpoint steps: font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem) scales smoothly without a jump at an arbitrary width. Two finishing touches that cost one line each: text-wrap: balance on headings so a title never leaves one orphaned word on its own line, and text-wrap: pretty on paragraphs to prevent single-word last lines. Demo 09 is the reference reader layout.

This is the layout problem every blog hits: the prose wants a narrow measure, but hero images and pull quotes want the full width. The clean modern answer is a named grid on the article with three column tracks — full-bleed, a wide breakout, and the content measure — using grid-template-columns: [full-start] minmax(1rem,1fr) [content-start] min(65ch, 100% - 2rem) [content-end] minmax(1rem,1fr) [full-end]. Every child defaults to the content column via grid-column: content, and anything that should escape simply says grid-column: full or grid-column: breakout. No negative margins, no calc(50% - 50vw) hacks, and nothing breaks when the container is not the viewport. The older negative-margin technique still appears in tutorials and it fails in two common cases: inside a container with padding, and when a scrollbar makes 100vw wider than the actual content box, producing horizontal overflow. If you need to support it anyway, overflow-x: clip on the wrapper contains the damage. Demos 07, 14 and 19 use the named-grid approach for full-bleed heroes, photo essays and inline newsletter callouts respectively.

position: sticky fails silently more often than any other CSS layout property, and it is almost always one of three causes. First, the sticky element's parent must be taller than the element — sticky positions within its containing block, so if the sidebar's parent is exactly as tall as the sidebar there is nowhere to travel. In a grid this bites when align-items: stretch makes the sidebar column full-height; set align-self: start on it. Second, any ancestor with overflow: hidden, auto or scroll silently makes itself the scroll port and the sticky stops working — use overflow-x: clip instead when you only meant to kill horizontal scroll. Third, sticky needs a threshold: top: 0 alone is fine, but if you have a sticky site header, offset by its height with top: calc(var(--header-h) + 1rem) or the sidebar will slide underneath it. For a related-stories rail that is taller than the viewport, make the rail itself scrollable with max-height: calc(100vh - 2rem); overflow-y: auto. Demo 15 implements the full pattern.

Getting this right serves accessibility and SEO with the same markup, so it is worth doing once properly. The post is an <article>, and its heading is the page's single <h1>. Metadata goes in a <header> inside the article, with the publication date as a real <time datetime="2026-08-10"> so machines get an unambiguous value while humans read the formatted version. Section headings step down without skipping levels — an <h2> never jumps to <h4>, because screen reader users navigate by heading level and gaps read as missing content. Images that carry meaning use <figure> with <figcaption>, and decorative ones get an empty alt="" rather than being described. A related-posts rail is a <nav aria-label="Related stories">, not a bare div. Author details belong in the header near the byline rather than only in a footer bio. On the SEO side, this structure maps directly onto Article structured data — headline, datePublished, author, image — so you are not writing the same information twice in two formats.

The modern approach needs no scroll listener at all. Scroll-driven animations bind a keyframe animation to scroll position: animation: grow linear both; animation-timeline: scroll(root block) with keyframes moving transform: scaleX(0) to scaleX(1). Because it runs off the main thread, the bar stays smooth even while JavaScript is busy. Scale rather than animating width — width triggers layout on every frame, transform does not. To track only the article rather than the whole page, give the article view-timeline-name: --article and point the bar at it, so progress starts at the first paragraph instead of the masthead. For browsers without scroll timelines, a rAF-throttled listener writing a single custom property is about fifteen lines and the visual CSS stays identical; gate it behind CSS.supports('animation-timeline', 'scroll()') so modern engines never run it. On accessibility: a progress bar that merely duplicates the scrollbar is decoration and should be aria-hidden; one that communicates something the scrollbar does not needs role="progressbar" with a live aria-valuenow. Demo 07 ships both paths.

Match the layout to how people actually arrive and what they do next. A magazine or news homepage with a dense grid works when you publish daily and readers browse — the grid signals volume and freshness, and the breaking-news bar earns its place only if it genuinely changes. A personal or dev blog is better served by a chronological archive with sticky year separators: low volume, high intent, and readers often want to see the whole body of work. Newsletter archives suit an issue-numbered list because subscribers think in issues, not dates, and an inline subscribe form converts best mid-list rather than in a modal. Recipe and photography blogs are image-first, so lock the aspect ratio and let the picture lead. Developer tutorials benefit from the two-column sticky code panel — readers scroll prose while the relevant code stays visible, which removes the constant scroll-back. Long-form journalism and case studies want the centred single-column reader with breakout images, because anything in the margins competes with a piece someone committed ten minutes to. The general rule: the more the reader has committed, the less chrome the layout should have.

Yes, and layout is where both are won or lost. Every template uses semantic sectioning — article, header, nav with a discernible label, figure and figcaption — so assistive technology gets structure rather than a soup of divs. Heading levels never skip. Every interactive control is a real button or a with a visible :focus-visible ring at 2px minimum and 3:1 contrast, and hit targets are at least 44 by 44 CSS pixels. All motion is guarded by prefers-reduced-motion: reduce. On performance, the layout choices matter more than any script: images carry explicit dimensions or a locked aspect-ratio so cumulative layout shift stays at zero, which is the single most common blog CLS failure. Fonts should use font-display: swap with a metric-compatible fallback so text is readable during load without reflowing. The sticky sidebars and progress bars animate compositor-only properties, never width or top. And because 12 of the 20 need no JavaScript at all, there is nothing to hydrate before a reader can start reading.

These are page layouts rather than components, so they usually become a layout file or template rather than a widget. In Astro — which is what this site runs on — a blog layout is a .astro file in src/layouts/ with a <slot /> where the content collection renders; the CSS drops in unchanged, and 12 of the 20 need no client directive at all because they ship no JavaScript. In Next.js App Router, the equivalent is layout.tsx for the shell plus a page component for the article body; only the reading progress, filter bar and a few interactive demos need 'use client'. For WordPress, the markup maps onto single.php and archive.php, or a block theme's templates/single.html; the scoped class names avoid collisions with whatever the parent theme already ships, which is the usual pain there. Ghost and Hugo follow the same shape with their own template syntax. For Tailwind v4, the grid track definitions and the named breakout columns are worth keeping as plain CSS in a @layer rather than translating to utilities — a grid-template-columns with named lines is far more readable as CSS than as an arbitrary-value class.