Project: Responsive Article Page
Introduction
A high-quality article page is one of the best CSS practice projects: typography, readable width, responsive media, code blocks, and navigation all matter. In this project, you will build a responsive article layout that remains readable across phone, tablet, and desktop screens.
Prerequisites
- Basic HTML and CSS workflow
- Understanding of responsive layout and media queries
- Familiarity with typography and spacing best practices
Project Goal
Build an article page with:
- hero title and metadata
- optional table of contents
- readable content column
- styled headings, paragraphs, lists, code blocks, and quotes
- responsive images
- mobile-friendly layout behavior
Quality targets:
- comfortable reading line length
- clear visual hierarchy
- strong accessibility and keyboard usability
Folder Setup
responsive-article/
├── index.html
├── css/
│ └── styles.css
└── images/
└── article-cover.jpgStep 1: HTML Structure
Create index.html:
Structure explanation:
- skip link improves keyboard navigation
- optional TOC lives in an
aside - content uses semantic sections with anchor IDs
- article body includes key content types (paragraph, list, quote, code)
Step 2: Base Tokens and Global Styles
Create css/styles.css:
Code explanation:
- tokens centralize design values
- global
border-boximproves sizing predictability - responsive image baseline prevents overflow
Step 3: Container and Page Shell
Add:
This keeps page width controlled and header visually stable.
Step 4: Two-Column Article Layout (Desktop)
Add:
Code explanation:
- mobile default is single column
- desktop switches to TOC + article columns
- sticky TOC improves long-article navigation
Step 5: Typography and Reading Rhythm
Add:
This creates stable rhythm and hierarchy for long-form reading.
Step 6: TOC and Link States
Add:
TOC remains scannable and link interactions stay keyboard-visible.
Step 7: Quote and Code Block Styling
Add:
Code explanation:
- quote gets strong visual cue without overpowering text
prehorizontal scrolling protects layout on small screens
Step 8: Mobile Optimization
Add:
@media (max-width: 979px) {
.toc {
order: -1;
}
}
@media (max-width: 640px) {
.article {
padding: var(--space-3);
}
}Code explanation:
- on small screens, TOC appears before article body
- reduced padding preserves content space on narrow devices
Step 9: Skip Link for Keyboard Users
Add:
This enables quick jump to main content for keyboard navigation.
Quality Checklist
- Main text remains readable at mobile and desktop widths
- TOC links work and are keyboard-focus visible
- Images and code blocks do not overflow layout
- Heading hierarchy is consistent
- Quote and code styles are readable with good contrast
Common Mistakes
| Mistake | Why it hurts | Better approach |
|---|---|---|
| Full-width article text on desktop | Hard reading and eye fatigue | Constrain content width |
| No code block overflow handling | Horizontal page break | Add overflow-x: auto to pre |
| Sticky TOC without layout checks | Overlap or unusable on mobile | Enable sticky only on larger screens |
| Removing link decoration entirely | Lower discoverability | Keep clear link cues |
| Missing skip link/focus style | Poor keyboard UX | Add skip link and focus-visible states |
Stretch Goals
- Add active-section highlighting in TOC (JS enhancement)
- Add reading progress bar
- Add dark mode token overrides
- Add print stylesheet for article output
- Add responsive image
srcset+sizesoptimization
FAQ
Should TOC always be sticky?
Only when viewport height and layout context make it usable. For small screens, static TOC is often better.
What is a good article line length?
A common practical range is around 60-75 characters per line for long-form readability.
Should code blocks wrap lines or scroll horizontally?
Horizontal scrolling is usually safer for preserving code formatting, especially in technical docs.
Is two-column layout required for article pages?
No. Single-column is often best on smaller screens. Two-column layout is an enhancement for wider displays.
How can I make this project reusable?
Extract tokens, article typography rules, and TOC component styles into modular CSS files and reuse them across documentation pages.