When Chrome Print Preview Differs From DevTools View

John Locke

John Locke is a SEO consultant from Sacramento, CA. He helps manufacturing businesses rank higher through his web agency, Lockedown SEO.

This one’s for the web developers in the house.

If you’ve ever tried to debug print styles in Chrome, and kept wondering why the print preview looked totally different than what you were seeing in Chrome Developer Tools, you were exactly where I was earlier this week.

Turns out the root of your problems may end up being a detail you never even realized might affect print styles.

Note: If you have an Angular application, you will need to seek another solution. The way Angular renders the pages is not compatible with the method for previewing print styles described below.

The Backstory

A client project I’ve been working on has one component that is reliant on printing pages for regular internal distribution.

On the pages they will need to print, the main content is dynamically generated — meaning it is written to the web page after the page initially loads.

In order to get initial print styles calibrated for each “view” of the page content, I was using Chrome, because of it’s ability to adjust print styles while still in the browser.

Emulating Print Styles In Chrome Developer Tools

The Chrome browser has a nifty feature in it’s Developer Tools where you can emulate different devices, or even print styles.

To access Chrome Developer Tools, right-click a page and select Inspect Element. The Chrome Dev Tools window will appear.

There are a ton of options here, but let’s look at how we emulate print styles for debugging.

In the top-left corner of the Dev Tools window, you’ll see a icon for toggling device emulation on and off. Go ahead and click that.

You should see a grid — with the page the browser is on — appear in another window behind the main Dev Tools window.

In the top-left corner of that window, there should be a drop-down menu for selecting what device and width you wish to emulate.

There’s one last thing we need to do to emulate print styles in the browser.

In the main Dev Tools window, you’ll see a split-screen window, which you can drag to adjust.

The left window has a set of tabs, which defaults to Elements, which is the HTML of the page the browser is looking at.

The right pane of the window also has a set of tabs, which defaults to Styles. Whatever HTML element you click on in the left panel, the CSS styles are shown in the right panel.

There is also a third adjustable panel at the bottom of the Dev Tools window.

If you drag this upwards, you’ll see a set of tabs for this panel. Click on the third tab, labelled Emulation.

In the menu on the left, choose Media. Check the box marked CSS media, and select print from the list of emulated media.

You should now see emulated print styles on the grid window open behind the main Dev Tools window.

Front-end developers who use Developer Tools or Firebug to test styles in the browser should now be able to test print styles without going to Print Preview first.

Here’s The Problem

So, as far as I could tell, some of the the print style rules I was adding weren’t taking effect when I went to print the page.

What was going on?

When I added this rule to my print styles, the style rules I had written before now worked!

/**
 * The asterisk targets all HTML elements in a web page.
 */
@media print { 
  * {
    -webkit-transition: none !important;
    transition: none !important;
  }
}

So what’s going on here? Why should the transition property even affect print styles at all?

The Explanation

In Chrome, the print preview generates before any element transitions are applied to the page.

Since the content on these particular pages was being added dynamically, any transition rules were being applied to them after I generated a print preview.

This blocked some of my CSS print styles from being applied. If you’re using transitions for responsive layouts, menus, or dynamic content, you may also get bitten by this browser quirk.

The Moral Of The Story

Debugging and testing are crucial parts of the web development cycle. Even for small projects, you have to allocate time and resources to cover testing.

The other thing I take away from this (and all web development) is that things almost always take longer than you anticipate they will. Leave yourself enough margin in your projects to do things right, and do more testing before launching.

John Locke

John Locke is a SEO consultant from Sacramento, CA. He helps manufacturing businesses rank higher through his web agency, Lockedown SEO.