A4 Paper Broke My Responsive Layout — and Made the Product Better

Most frontend work trains us to think in flexible dimensions.

The viewport changes. Components stretch. Text wraps. Images crop. If something gets a little taller, the rest of the page moves down.

Then I tried to print four game cards on one sheet of A4 paper.

Suddenly, none of that flexibility was helpful.

I ran into this while working on WYRPlay, a Would You Rather game I’ve been building for families and kids.

The web version was already responsive.

I thought printing would mostly mean hiding the navigation, adding @media print, and calling it done.

It was not.

Paper has an API, and it is extremely strict

My target sounded simple:

• A4 landscape
• four cards
• two columns
• two rows
• consistent outer margins
• consistent gaps
• nothing spilling onto a second page

On a screen, being off by a few pixels usually doesn't matter.

On paper, a few millimeters can be the difference between four cards on one sheet and the fourth card appearing alone on page two.

That changed the problem completely.

I was no longer designing for:

available width → responsive layout 

I was designing for:

fixed page - margins - gaps - card geometry = exact usable area 

There was nowhere for overflow to go.

My first instinct was to make a separate PDF system

That would have been the obvious architecture.

The web app renders one version.

A PDF generator renders another.

Something like:

Question data ├── Web UI └── PDF template 

It gives you a lot of control.

It also gives you two presentation systems to maintain.

That bothered me more than the print problem itself.

If I changed a question layout, I would eventually need to remember the PDF version.

If I fixed an illustration bug, there would be two rendering paths to check.

And if the printable experience became more important later, I would effectively be maintaining a second product.

So I tried a different approach.

Same content, different rendering rules

The breakthrough was realizing that I didn't need the screen UI to become printable.

I only needed the same content to have a print presentation.

That sounds like a small distinction, but it cleaned up the architecture.

The model became:

Question ↓ Shared content ↓ Screen presentation Print presentation 

The web version is free to be responsive.

The print version is free to be rigid.

Neither one has to pretend it lives in the other's environment.

That meant I could use print-specific CSS for the physical geometry without creating a completely separate content pipeline.

Responsive design became the wrong tool

This was probably the strangest part.

In normal frontend work, making something more responsive is usually an improvement.

For the print layout, I wanted almost the opposite.

I wanted predictable dimensions.

Predictable gaps.

Predictable image areas.

Predictable text regions.

Predictable page breaks.

A printable card needs to know where its boundaries are.

So instead of asking:

What should this component do at 768px?

I was asking:

How large can this card physically be after page margins and gaps are removed?

It felt closer to designing packaging than designing a website.

The hardest variable wasn't CSS

It was the content.

A rectangle has predictable dimensions.

A sentence does not.

One Would You Rather question might be:

Fly or breathe underwater?

Another can be several times longer.

A responsive web card can simply grow.

A physical card on a 2 × 2 A4 sheet cannot.

That meant typography wasn't just decoration anymore. It became part of the layout constraint.

Font size, line height, padding, illustration height, and maximum expected question length all affected each other.

Eventually I realized I needed to think in terms of a content envelope.

The card wasn't designed for arbitrary text.

It was designed for a known range of question lengths.

That also changed how I wrote and reviewed the content itself.

Sometimes the correct frontend fix was not another CSS rule.

It was shortening the sentence.

Illustrations had the same problem

WYRPlay uses illustrations for many of its questions.

On a responsive screen, slightly different source compositions can still look acceptable.

Printed next to each other, inconsistency becomes obvious.

One subject is too close to the edge.

Another image crops differently.

Another has a focal point in the wrong place.

Four cards on the same physical sheet expose those differences immediately.

So the print feature ended up changing how I thought about image production too.

The source illustrations needed more consistent composition before CSS ever touched them.

That was unexpected.

I thought I was implementing printing.

I ended up changing the asset pipeline.

@media print is only the beginning

The CSS itself wasn't especially exotic.

The difficult part was deciding what the print environment actually required.

Things that suddenly mattered included:

• @page
• physical units
• print margins
• page-break behavior
• whether backgrounds are printed
• image cropping
• browser scaling
• text overflow
• elements that should disappear entirely

And then there is the print dialog.

A layout can look perfect in the browser and still surprise you there.

Margins get added.

Background graphics disappear.

Scaling changes.

Text wraps differently.

So Chrome's print preview became part of my development loop instead of something I checked at the end.

That was another mindset change:

print wasn't an export step anymore. It was a rendering target.

The final system is intentionally boring

That's probably a good sign.

There isn't a complicated PDF service.

There isn't another database of printable questions.

There isn't a manually designed file for every card.

The same content feeds two layouts:

 Question data │ ┌────────┴────────┐ │ │ Screen UI Print UI │ │ responsive fixed A4 

The screen experience optimizes for devices.

The print experience optimizes for paper.

They share the thing that should be shared — the content — and disagree about the thing that should be different — the layout.

The print button changed more than I expected

I started with what sounded like a minor feature:

Let people print the cards.

But forcing the product onto a fixed physical page exposed assumptions that the responsive version had been hiding.

It made me define card geometry more carefully.

It made me think about maximum content length.

It made the illustration format more consistent.

And it forced a much cleaner separation between content and presentation.

In that sense, A4 paper broke my responsive layout.

I'm glad it did.

Sometimes a less flexible rendering environment is exactly what exposes the flexibility your architecture was relying on too much.