If any of you have played around with a print style style sheet on a complex theme or site you might already be familiar with the fact that print CSS does not always operate the way you would expect or desire. If you have not yet experienced the familiar urge to ram your head through your computer screen, I hope to save you from that experience with a few tips and tricks I picked up while learning to troubleshoot print style sheets.
Before we jump in, I want to ensure you’ve got some useful tools right off the bat to help set you up for success.
What you need
First, make sure you’re working on a browser that allows you to turn on a print emulator. This will make troubleshooting go a lot faster. However, be forewarned, while the print emulator shows the elements you will be printing and their style sheet rules, it does not necessarily visually represent perfectly what the printed page will actually look like. Frequently check your changes by either printing or viewing/downloading them as a PDF to confirm you’re getting the desired results. You will be sorely disappointed to get things pixel perfect in an emulator only to discover the printed result is vastly different.
Additionally, make sure your browser’s print scale is set to 100%. While you don’t have control over what your users will do with their browsers, there is a good chance many users won’t have changed their browser print settings. Therefore, you want to save yourself any headaches where you think you’ve developed correctly only to discover that you had been in the wrong scale.
I pretty much exclusively develop on Chrome and then check on other browsers to ensure things are working as desired. This Stack Overflow will show you how to turn on Chrome’s print emulator in various different chrome versions. Google “Print Emulator [browser name]” if you prefer to work in something besides Chrome.
Below is a list of issues I have commonly faced and some solutions that rectified them. I hope they can save you time and hours of googling or shooting in the dark.
Printing extra blank pages
No one wants to print something only to find many blank pages at the end or, worse, the timestamp of the print job on an otherwise empty sheet of paper. This is frustrating at best and can cost some companies their customers if printing from the web is a common enough function of their users.
Display vs. visibility
There are a few different things that can cause extra blank pages to print. The most common culprit is having an element displaying on the page that you don’t need. If you need to hide or get rid of an element for printing do not use visibility: hidden. Instead, in 99% of cases, you’re going to want to use display: none, because that will hide the element as if it didn’t exist in the DOM, whereas visibility: hidden will still allow the element to exist and take up space, even though you won’t see it anymore. If it’s taking up space, it’s going to get “printed,” even if all that comes out is a blank page. (And it might not even seem to be showing up where you would expect, but still has an impact on the layout when printed).
I just fixed a bug for a client where someone added an element and then used visibility: hidden instead of display: none for print. After I got rid of the element with display: none, the undesirable extra blank page disappeared. Another unforeseen bonus was that my printed pages went down from thirty-three to twenty-one pages.
Turns out, some of my tightened spacing that was intentionally crafted to decrease the number of printed pages was re-added to not very noticeable places by this hidden element, even though logically it should not have had any impact on the spacing. Did I mention before that print style sheets are a bit wonky? display: none helped me solve the problem.
Removing :before and :afters
A lot of themes or sites commonly use :before and :after for clearfixes, but when it comes to printing, they are often not necessary. If there is no obvious element or rule that is a problem and yet you are still getting blank pages, there is fair chance that some of those :before and :afters are causing a problem.
Try display: none with them and see if your problem resolves. Additionally, sometimes you find an element you know needs to be removed, and yet even after removing it with display: none, you still have an extra blank page. Sometimes you need both the combination of removing the element and :before and :afters of a parent or nearby element for the extra page to go away.
Padding and margin
This is another really common culprit when it comes to extra blank pages.
On a website, you want to have white space around your elements for readability and aesthetic, but when you’re printing, the paper will automatically have margins. Having padding or margins, especially on parent or high level elements like html or body can often result in added blank pages or funky page breaks. Ideally, in your print emulator, you’ll most likely want to see your content stretched all the way across the browser with no white space around it. It’ll look ugly to your eye, but correct when it prints. You might have to include every element that will be touching the paper’s physical margin and get rid of all left and right padding and margins around those elements.
Media queries
Lastly, this isn’t always a factor but it can show up. Your other media queries can impact printing. Most likely when you’re developing you’re working on a wider screen than the page that you’re printing. Therefore, some of your media queries might have some rules or different things that you’re not necessarily seeing play out when you’re printing. Remember: it doesn’t matter what kind of device you’re printing from. Printing the same page from a phone or a gigantic screen will have the same print out. So be sure there aren’t media query rules that could be throwing a wrench into the works.
Undesirable page breaks
Another common printing woe is having your content break awkwardly over the printed pages. It’s important to note that, most likely, if your page is breaking funny, you’re probably not dealing with a plain article. I’ve found most pagebreak issues are for pages that have tables or other more complex layouts that need to be maintained when printed.
Page-break-* and break-* not working
Depending on your content, there are likely places that you don’t want a page break. For example, if you have a table and a title for the table, you don’t want a page break between the table and title, they go together as a packaged deal. Additionally, there are places that a page break would be appropriate. A paragraph element broken up over two pages is normative. If you have a table and some copy, you probably would rather the copy have a page break than the table. Fortunately, there are some CSS declarations (page-break-before, page-break-after, page-break-inside) to help break things up intentionally. Unfortunately, there are other factors that can impact the effectiveness of these declarations.
Let’s look at some HTML and CSS to walk through some of the stickiness with page-break-*
<body>
<main>
<p>Communication and copy…</p>
<h1>Title of Table</h1>Communication and copy…</p>
// Your
HTML here
</main> <aside> //Sidebar stuff that you won’t need in print </aside> </body>
In the above example, it’s safe to say you want the table to come directly after your title, with the table fully displayed on one page, followed by the copy.
Therefore, you’d probably write some CSS like this:
h1 {
page-break-after: avoid;
}
.table {
page-break-inside: avoid;
page-break-before: avoid;
}
In essence, you’re saying you want the title and the table to be right next to each other with no page breaks between them, and you don’t want the page to break in the middle of the table. If you were to print this page out, there is a high chance you won’t get your desired results, but why?
Any parent items that are floated won’t allow the page-break-* rules to work as desired. If you look again at the HTML, you’ll see the main and aside elements. There is a good chance that the main element is floated to the left and the asideto the right. Even though you are no longer displaying the aside in your print style sheet, the main element is still floated.
There, that’s much better! Setting main to float: none; allowed the page-break-*s to work.
Also, important to note: I almost exclusively make my tables with divs using display: table, table-cell, table-row, etc., instead of table elements, to allow flexibility with responsive tweaks at different breakpoints. I’ve heard page-break-* doesn’t work great with actual table elements but I can’t comment on that, as that’s not in my wheelhouse.
IE & Edge margins
If you’ve been developing for any time at all, it is probably not surprising to you that Internet Explorer commonly has some roadblocks.
I noticed pages that had no trouble printing on other browsers would have unexpected page breaks in funny places on IE or Edge.
After playing around with the browser settings, I discovered that IE and Edge give slightly wider margins than other browsers. I wouldn’t be surprised if they’re trying to get their print pages to emulate the default margins on Microsoft Word. As a user, you can change the margins to narrow in the print settings, which will get the page to print out as it does with other browsers. However, from a UX perspective, it’s not great for IE/Edge users to be forced to change their browser settings just to print.
We decided to decrease our font size on the page and that allowed the content in our tables to fit within the wider margins that IE/Edge bring to the table. While this solution worked in my single use case, it might not be ideal for every situation you encounter. The idea is to think creatively and try stuff out; this is one way you can start.
Extra content
Occasionally, you have a set design where you want a table or calendar to all print on one page. However, the content that goes in that table or calendar might change depending on user interaction or the functionality of the page. Often, in development, it is hard to catch all the particular edge cases you’ll run into on production. Therefore, everything might seem good to go and then once live it breaks due to extra content you didn’t foresee.
If content will change and your print page takes up almost every ounce of surface area of the page, there is a good chance that you don’t have enough leeway to account for instances where there is a higher than average amount of content.
A helpful fix can be to decrease the font-size so more things fit. That is not always feasible so you may have to explore decreasing the width of your elements so that there is more room on the page than you need.
It’s not always obvious that the extra content is causing the problem because if you are using page-break-* declarations it might show up in unexpected places.
While print style sheets may not be the most fun to work with, they don’t have to be the bane of your existence. I hope that some of these tips and tricks help save your sanity and time. I’ve also found that, when it comes to print style sheets, solutions often are a combination of things (i.e. you need something to be display:none and the padding of another element to be changed), while doing one or the other won’t fix the problem.
Do you have any tips or tricks you’ve stashed in your tool belt from working on print style sheets? Please share them below in the comments.