Here is a scenario that plays out on almost every CMS project. A developer builds a blog theme, everything looks sharp in the browser, the client approves it, and then the first real post goes live. The H2 has no top margin because there was never an H2 in the test content. The image stretches past the container because max-width: 100% was not set on img inside .content. The table scrolls horizontally inside a column that was designed with text in mind. The numbered list inherits a margin-bottom that makes sense for paragraphs but looks wrong between list items.
None of this showed up in development because the developer tested with lorem ipsum — a wall of uniform paragraphs with no structure, no inline formatting, no media, and no data. Lorem ipsum is a lie of omission. It tests one thing — that your p tag renders — and quietly lets everything else slip through untested.
The elements lorem ipsum never touches
Think through every element a content editor can realistically produce in your CMS of choice. On WordPress with Gutenberg, that list is long. On Contentful or Sanity, it depends on your schema, but it is never just paragraphs. Each one is a potential breakage point if your CSS was written without it in mind.
Heading hierarchy
Headings are the most commonly broken element in CMS themes. The issue is rarely the heading itself — it is the spacing relationship between a heading and whatever precedes or follows it. A margin-top that looks correct on an H2 following a paragraph often looks too tight when the H2 follows another heading, and too loose when it is the first element in the content area. You only find this when you test with a realistic heading sequence, not with a single heading sitting in isolation.
Lists in context
Unordered and ordered lists seem straightforward until they appear inside a block of prose. Most CSS resets strip browser list styles, which means you have to add them back explicitly. Developers often forget that list-style: disc without padding-left renders bullets outside the content area, and that a list following a paragraph needs different spacing than a list following a heading. These issues only appear when a list sits inside real content, not when it is the only element on a test page.
Inline formatting
Bold, italic, and linked text are used constantly in editorial content. They are almost never used in lorem ipsum. The practical problems this causes: link colour that is invisible against the body text colour, font-weight: bold that shifts the line width enough to cause reflow in a narrow column, and em rendering incorrectly when the body font is a variable font with a separate italic axis. You can only see these issues when bold, italic, and linked text appear mid-sentence, embedded in paragraphs of real length.
Media and figures
Images in CMS content are almost always wrapped in a figure with a figcaption. Editors upload images at whatever resolution they have available, which means your CSS needs to constrain them. Without max-width: 100% on images inside the content container, large uploaded images blow out the layout. Without explicit margin on figure, images run hard against the surrounding text. Caption styling is often missed entirely because lorem ipsum does not produce captions.
Tables
Tables are the hardest content element to style responsively, and the most commonly ignored in CMS development. A table with six columns on a 1400px monitor looks fine. On a 375px phone it scrolls horizontally if you are lucky, or overflows and breaks the page layout if you are not. Wrapping tables in an overflow-x: auto container is the standard fix, but it only gets applied if the developer actually tested the layout with a table in it.
The fix is configuration, not creativity
The solution is not to hand-write test content before every project. That takes too long and produces inconsistent results. The solution is to generate structured placeholder content that matches the element mix your editors can actually produce, and use it as the baseline for all layout testing.
The workflow is straightforward. Before you write a line of CSS for your content area, decide which elements your CMS schema supports. Configure your placeholder content to produce exactly that mix — headings at the right levels, lists with a realistic item count, images at the size your editors typically upload, a table if your schema allows tables. Generate it, paste it into your layout, and test everything at once.
Save that output as a fixture file in your project. A single HTML file checked into version control gives every future CSS change a realistic baseline to test against. When you revisit the project six months later to update the typography, you have something to check your changes against beyond a blank page.
What this looks like in practice
A reasonable test fixture for a standard blog or editorial layout should include: three or four paragraphs, two heading levels, at least one unordered list, at least one ordered list, a paragraph with bold and linked text, a figure with an image and caption, a blockquote, and a table. That covers the output of every standard CMS block type an editor is likely to use.
It takes two minutes to generate and it will save significantly more time than that in debugging and client revisions. The only question is when you generate it — before you write the CSS, or after an editor finds all the breakages for you in production.