Nobody prints anything

#css #ecommerce

---

One of our account managers got a call about how a client’s order confirmation page printed across several sheets of paper. A couple of the sheets were blank except for a bit of navigation and one had the actual order details split down the middle. It came over to me with a screenshot of each sheet.

Honestly, my first thought was “Who is even printing this?” The account manager asked. Turns out the client’s 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.

I’d figured print styles were pointless and I’d never once checked, which is a skill issue on my part and not the browser’s.

Who is actually printing

Once I started asking, it kept coming up. Nobody prints a blog post but plenty of other things get printed.

Order confirmations and invoices go in a folder because that’s what the bookkeeping process is. People print tickets and boarding passes when they don’t trust their battery or their data. Recipes end up strewn across a kitchen counter. Directions and hours get printed for someone who isn’t sure about the maps app on their phone.

Then there’s anything a lawyer or an accountant touches, anything that needs a signature, and 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. Somebody wants your content without all the other bells and whistles alongside it.

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 picks up the phone when there’s a problem.

A little bit goes a long way

Once I sat down to fix it, I was surprised by 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. That’s the nav, the sidebar, the footer, the share buttons, the cookie notice, the search box, and the thing that says “related articles.”

print.css

@media print {
  .site-header,
  .site-nav,
  .site-footer,
  .sidebar,
  .share,
  .cookie-notice { display: none; }
}

CSS

Stop things from breaking across pages. A table row split down the middle of a page is the specific failure that started this. Putting 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 end up with a heading alone at the bottom of a page and its section on the next one.

print.css

@media print {
  tr, img, blockquote, .card { page-break-inside: avoid; }
  h1, h2, h3 { page-break-after: avoid; }
  p { orphans: 3; widows: 3; }
}

CSS

Deal with links. 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:

print.css

@media print {
  a[href^="http"]:after {
    content: " (" attr(href) ")";
    font-size: 90%;
  }
}

CSS

I’d use that with some judgment though. On a page with 40 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. For some pages I’d just skip it entirely.

Then set the type for paper. Use points instead of pixels because points are a physical unit and the whole context is physical. Make it black on white since colored text on a monochrome printer turns to gray mush.

Print-edition gotchas

There were 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. Set position: static, float: none, and 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 figure out because it looks like the content is missing instead of 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 wouldn’t 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. There’s plenty from before my time and then it drops off a cliff.

I think that’s 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, and 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 comes up as a complaint when it’s wrong.

Every site looks the same on paper

I put those 40 lines in a partial and I’ve now copied that partial into a few projects, adjusting the list of things to hide. 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.