
When Chrome Print Preview Differs From DevTools View
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.
I was losing my mind with this problem. I was unable to make those margins disappear on
@media print
, and after hours searching on the net, this was the first logical explanation I could find.I tried it, and worked!
Thanks a lot John!
Happy to be of service, Sergio! 🙂
Still doesn’t work for me. I have an AngularJS app that dynamically loads and compiles a template and inserts the resulting content into a portion of the page that’s hidden until print. I put the above style in a @media print section of my stylesheet and I cannot get the printed output to look correct (i.e. how it looks in print emulation mode).
Hi Buddy:
Unfortunately, if the page template is being dynamically compiled after page load, the Chrome print preview isn’t going to work the same way as it would for a normal page.
It sounds like your situation is similar to the problem that inspired this article, but with extra steps involved. 🙁
John, I’m having the same problems as Buddy, is there any resource you know of to help with this Angular issue?
Hi Megan:
It sounds like in Angular builds, the page renders after Chrome initially loads the page. This sounds like your situation isn’t just using CSS transitions to responsively change the page layout, but generating content that would appear after Chrome generates a print preview.
For now, there doesn’t seem to be an easy way to adjust the print CSS for Angular builds in Chrome. Hopefully, the Chrome team will address this in the near future.
Hey John,
Thanks for sharing a great solution for print media.
However, it looks like it is not supported in Angular applications.
Hi Kalpesh:
Yes, many people have commented on that. This works for pages and applications that are using something besides Angular to render the page.
The method in the article above does not apply to Angular applications.
Thanks,
John
You rock! Couldn’t figure this out until this post. Thanks so much!
Thanks for stopping by Tony! This one kept me going round and round too for a while. Have a great weekend.
Thank you!
You’re welcome! This drove me crazy, too.
Hi John,
Any ideas why PDF media is not following the same rules as Print? I am having this issue that print optimized pages of my HTML looks fine in print window or in print emulated tool in Chrome. However when trying to generate a PDF same rules does not apply?
Hi Kathy:
It might be the way the PDF settings are on your computer, or any number of other things. Would be difficult to say without actually seeing what you are seeing. If you are doing
Print > Send to PDF
, and it’s not doing what you believe it should, you might need to adjust something on your end (with the PDF creation).– John