Nobody prints anything
An order confirmation page that printed across several sheets, and the 40 lines that fixed it.
I got a call about how a client’s order confirmation page printed across several sheets of paper, a couple of which were blank apart from a bit of navigation and one of which had the actual order details split down the middle.
Honestly, my first thought was: who is even printing this? The answer turned out to be their warehouse was printing every single order because that’s how the picking process works and has worked for however many years they’ve been in business.
So that’s the post. I figured print styles were pointless and I’d never once checked.
Who is actually printing
Once I started asking, it kept coming up. Not for content, nobody prints a blog post, but for things like…
Order confirmations and invoices, which go in a folder because that’s what the bookkeeping process is. Tickets and boarding passes, where the person doesn’t trust their battery or data. Recipes, strewn across a kitchen counter. Directions and opening hours for someone who isn’t sure about the maps app on their phone. Anything a lawyer or an accountant touches. Anything that needs a signature. Anything that has to go in a physical file because some agency says so.
There’s also “print” that isn’t paper: save as PDF goes through exactly the same stylesheet, and that’s how a lot of people archive things now. And reader mode in browser extensions isn’t exactly print, but it’s the same instinct which is somebody wanting your content without all the other bells and whistles alongside it.
I'd spent two years assuming print styles were pointless and I'd never once checked.
None of that is a big audience. It’s a small audience with a sharp need, which is a different thing and it’s the kind that calls you when there’s a problem.
A little bit goes a long way
The thing that surprised me, once I sat down to fix it, is how little there was to do. This isn’t a whole thing. It’s about 40 lines and I’d just never written them.
Hide the bells and whistles. Nav, sidebar, footer, share buttons, cookie notice, the search box, the thing that says “related articles.”
@media print {
.site-header,
.site-nav,
.site-footer,
.sidebar,
.share,
.cookie-notice { display: none; }
}Stop things breaking across pages. A table row split down the middle of a page is the specific failure that started this, and page-break-inside: avoid on the elements that shouldn’t be cut fixes most of it. Headings get page-break-after: avoid so you don’t get a heading alone at the bottom of a page with its section on the next page.
@media print {
tr, img, blockquote, .card { page-break-inside: avoid; }
h1, h2, h3 { page-break-after: avoid; }
p { orphans: 3; widows: 3; }
}Deal with links, because a link on paper is just underlined text and whatever it pointed at is gone. You can print the destination after it, which is the classic trick:
@media print {
a[href^="http"]:after {
content: " (" attr(href) ")";
font-size: 90%;
}
}I’d use that with some judgment though. On a page with forty links in the prose it makes the text unreadable, and on internal links it’s just noise. I’ve settled on doing it only for external links and only in the main content, and honestly for some pages I’d just skip it entirely.
Then set the type for paper. Points rather than pixels, because points are a physical unit and the whole context is physical. Black on white, since colored text on a monochrome printer turns to gray mush.
Print-edition gotchas
A few things I didn’t anticipate:
Anything positioned or floated behaves oddly across a page break, because the page break is a thing the layout model doesn’t really know about. The reliable fix is to undo it: position: static, float: none, width: auto inside the print query, and let it be a normal document.
Fixed headers are the worst version of this. A position: fixed header can print on every single page, or on none, depending on the browser. Set it to static or hide it.
Content in overflow: hidden or a scrolling container gets clipped at whatever was visible, so a long code block in a scrolling panel prints as one visible line. That one took me a while to work out because it looks like the content is missing rather than clipped.
And you have to actually test it. Print preview in the browser is enough for most of it and it’s two keystrokes. There’s also a DevTools option to emulate print media so you can inspect it properly. I’d not bother printing on real paper unless paper’s the actual use case, which for the warehouse it was so I did.
Why I think nobody does this
I went looking for writing about print stylesheets before I started, and there’s almost nothing recent. Loads from before my time and then it drops off a cliff.
Which I think is because it fell into a gap. It’s not new, so nobody’s excited about it. It’s not visible, so it doesn’t go in a portfolio. It doesn’t show up in analytics at all, so it never appears in a report. A thing that never appears in a report doesn’t get prioritized, and the people who need it are calling the client and not necessarily us.
That’s a decent description of a whole category of work, actually. The stuff that’s invisible when it’s right and only surfaces as a complaint when it’s wrong.
Every site looks the same on paper
Forty lines. I put them in a partial and I’ve now copied that partial into four projects, adjusting the list of things to hide, and it only takes a few minutes per site.
If you want to check whether you have a problem: open the thing on your site that’s most likely to be printed, maybe an order confirmation or a contact page or a long article, and hit print preview. That’s the whole audit. Unless you’re more proactive than I’ve been, my guess is you’ll find your nav on page one and your content starting on page two 🫠