Before you launch your brand-spankin’ new website, check your print styles! Why? Because your users will be printing your site, whether you like it or not. Even in a world dominated by glowing screens, some users prefer consuming content the old-fashioned way, or may need a hard-copy of a page of your site “just-in-case”.

Where to start?

That one’s easy. Interface designers have a media query that targets print for CSS styles that all modern browsers respect:

@media print {  .your-print-styles-here {  }  }

That should be the last declaration in your CSS file, by the way, to ensure that print styles override all other styles. You may also include a link to a separate print stylesheet, if that level of control is necessary. Just make sure it comes after your main stylesheet(s) in the head of your document:

<link rel="stylesheet" media="print" href="css/PrintStyles.css"/>

The next step would be to set up your page:

@page {
        size: 8.5in 11in portrait;
        margin: 0.25in;

Be aware that users can override your page size and margins, though, and that not all countries use the 8.5×11” standard. Be sure to print at different page sizes, too, just in case something goes awry. The page rule is also a fairly new property, so browser support here might be limited as well to the most modern browsers. Test, test, and test some more!

Next, use the universal star selector to provide some useful resets:

*, *:before, *:after {
        background: transparent !important;
        color: #000 !important;
        box-shadow: none !important;
        text-shadow: none !important;
        transition: none !important;
        animation: none !important;
        transform: none !important;
        opacity: 1 !important;

What this CSS code will do is remove any background colors, turn your text black, remove any shadow styling, and remove any interactivity that might cause print layout bugs, and ensure everything prints at full opacity. The black color declaration isn’t necessary, but make sure any white text is printed as black if you choose to include it.

Also, be aware that if you decide to keep background colors in your print layout that users can decide to remove all background colors when they go to print your website. Be sure you don’t include any white text on a colored background, otherwise there’s a good chance text won’t print.

Use of the important declaration is normally avoided like the plague, but since we’re inside of our print media query and it’s the last bit of styling we’re providing for our site, it’s perfectly acceptable. (Specificity should be at its highest at the end of your stylesheet, which is what is happening here).

Hide, Hide, and Hide Some More

Print is a very different medium than a website inside of a screen. Gone are all of your interactions and cool animations. Your print styles should get everything out of the way between users reading the words on the paper. That awesome sticky header you stayed up late crafting? Hide it. The off-screen navigation you implemented for mobile users? Don’t even think about it.

A good catch all might be including something like this in your print media query if you’re using HTML5 elements:

header, nav, aside, footer { display: none; }
main {display: block }

An approach that could be right for you is to also include special helper classes in your CSS to show and hide elements for print media. This requires some planning and forethought on each element, though, which isn’t always possible.

.print-only-block { display: block }
.print-only-inline { display: inline }
.print-hide { display: none }

Fix All the Links

If you have any website links displayed on your site (such as, it’s a good idea to break the URLs so they wrap, if needed. This applies to displayed email addresses too. That declaration might look something like this:

a[href^="http://"], a[href^="www."], a[href^="mailto:"] {
        -ms-word-wrap: break-word;
        word-wrap: break-word;
        -ms-word-break: break-all;
        word-break: break-all;

Page Break Control for the Win

Don’t let your content be cut in half by the print. Declare page breaks judiciously on important blocks of content, like this:

tr, ul {
     page-break-inside: avoid;

h2, h3 {
        page-break-after: avoid;

Be careful about floating any parent elements when using page breaks – if you use floats, child elements won’t respect page breaks.

Inversely, there might be elements where you want to start a new page, such as top level headings and articles:

article, h1 {
        page-break-before: always;


Images are one of the key reasons why your users may print. Don’t let your images be cut off when printing by including this simple line of CSS:

img {
        max-width: 100% !important;
        page-break-inside: avoid;

This will ensure that the width of an image is only as wide as the printable area of the paper size, and it will tell the browser to avoid cutting off any images.

Best Practices & Gotchas

A best practice would be to make sure all of your non-print media queries include the screen declaration, like so:

@media screen and (min-width:1024px) {  .your-screen-styles-here {  }  }

That ensures your print styles will be inheriting mobile-first styles, which will set you up for print success. I’ve found that mobile device screen and print styles (font-sizes, line-height, and other base typographic styles) translate very well.

Another gotcha is transitions. This CSS property can add a lot of nice visual effects to a site on screen, but can wreak havoc on print styles, adding in many weird visual glitches in print previews and actual prints that are very hard to track down. Make sure you reset any transitions – my rule is to reset to none as outlined above.


  • (Included some nice examples)

This is the first blog post in a series about ALM. I have been a developer for many years (oh so many years), and ALM is very close to my heart. I’ve learned from experience that with good ALM, your chances of success increase considerably. Conversely, without it, you’re probably going to fail. I’m a huge fan and I want to share it with you. I’m going to tell you why you should care.

ALM, or Application Lifecycle Management, is the glue that holds your project together. Without ALM, you run the risk of your project being like a boat without a rudder. If your bright shiny new BMW has no steering wheel, you’re likely to run into a ditch before you’ve even left Munchkin Land.

If you’re leadership, you should be putting sound ALM practices in place. If you’re a developer, you should be asking for it. It doesn’t matter what role you play in the development process, ALM benefits everyone; from clients to managers to testers. Yes, we care about testers, too.

So what is ALM? We already know what it stands for, but it’s more than just 3 initials. Let me break it down for you. There are 3 main pillars of ALM: Visibility, Traceability and Automation. What does this mean and what tooling do we have at our disposal? I’m going to break it down for you.

Visibility – The Brains

Regardless of your role on a project, there are things you are going to want to know about it on a day-to-day basis. For example, if you’re the client, you might want to know what features are being worked on this week. A development manager might want to take a look at what tasks each developer is currently working on, and how much effort is left. A tester (see, I told you we cared) will probably want to see which features were marked complete yesterday so he knows what to test today.

This is all about visibility. By availing data to the team, we create a more informed, and therefore stronger, team.

Automation – The Heart

Visibility is all well and good, but without automation, it’s about as useful as a bottle of Evian to the Wicked Witch of the West. If the team is reliant on a person to publish status reports, or inform the product owner when a feature is complete, then human error and miscommunication will come into effect. In addition, manual processes will cost more than automated ones. This becomes especially evident when you consider build and deployment processes. Close your eyes and imagine for a second that the continuous integration build had to be kicked off manually. It just wouldn’t be practical. Okay, you can open your eyes now.

Traceability – The Courage

Courage isn’t really relevant here but I was enjoying the movie reference. Traceability is about being able to trace various artifacts in the project and link them together in a meaningful way. If you consider you could trace a code check-in back to the original requirement; or track a developer’s estimated effort against actual effort; you get an idea of how powerful traceability is.


You can imagine that if your 3 ALM pillars are solid, you have laid the foundations for success. There are several tools to help you build your pillars, and it is possible to buy them a la cart and integrate them. Our favorite here at the labs of Mercury New Media is Microsoft’s offerings, with VSO (Visual Studio Online) at the center. We use the task board to track features, user stories and tasks; integrated GIT repositories to store code and apply check-in policies; TFS builds that retrieve, build and deploy code on check-in and every night; and we get all the wonderful reports and charts, such as sprint burn-downs, with no extra effort. It’s just all there, and it all works together seamlessly.

If Microsoft’s offerings are not for you, there are many viable options out there. What’s important is that it all works together, and for you and your team.

What’s next?

I don’t know what’s next for you, but for me, I’ll be diving a little deeper into how we practice good ALM here at Mercury New Media. If your passion is Disney Princesses and sleepovers, my next post might not be for you. But if you want to geek-out on sandboxes, automatic deployments and unit tests, I’ll see you next time.