CSS Styling for Print and Other Media

CSS Styling for Print and Other Media

Got something to say?

Share your comments on this topic with other web professionals

In: Articles

By Ian Lloyd

Published on November 20, 2006

Note: This excerpt from the upcoming book “Pro CSS Techniques” by Jeff Croft, Ian Lloyd, and Dan Rubin, has been edited for this publication with permission of the chapter’s author, Ian Lloyd. The excerpt is approximately two-thirds of the length of the original chapter.

There are many different media types that you can apply to CSS, some of which are more useful than others, and they let you specify the look, feel, or sound of the web page that is linked to the CSS files. In this section, we’ll look at the various media types that are available (as gleaned from the official source, namely the W3C: www.w3.org/TR/REC-CSS2/media.html#q1). However, rather than list them all and suggest wonderfully practical ways to use them, we’ll break the list down into two categories: useful and not-so-useful (read: which ones you’re likely to use on a day-to-day basis in the foreseeable future, and those that you won’t touch in a month of Sundays).

The Useful Media Types

This list includes the media types that you will truly find a use for on regular occasions:

  • screen—For color computer screens
  • /files/includes/print.css—For /files/includes/print.cssed versions of the document
  • projection—For presentation or kiosk versions of the document (where toolbars are removed, and the display renders completely full screen)
  • all—For styles that are suitable for all devices

We’ll be using (or covering briefly) these media types in this chapter’s examples.

The Not-So-Useful Media Types

Remember what I was saying about those media types that you’d never use in a month of Sundays? Well, here they are, listed for your soon-to-be-ignored pleasure:

  • aural—For use with speech synthesizers or talking browsers
  • braille—For Braille-tactile feedback devices
  • embossed—For paged Braille /files/includes/print.cssers
  • handheld—For handheld devices (for example, small-screen PDAs and cell phones)
  • tty—For media using a fixed-pitch character grid, such as Teletypes, terminals, or portable devices with limited display capabilities
  • tv—For television-type devices

We won’t focus on these types because, while the reasoning behind them is good, support for their usage may be nonexistent. However, we’ll expand on the aural and handheld types in the section “Style Sheets for Other Media Types” later in this chapter.

Specifying the Media Type

Next, let’s look at how you can tell the user agent which medium (or media) the styles you are asking it to render should apply to.

Adding a media Attribute to the link Element

Arguably, the simplest method for linking to a style sheet is to use the link element, like so:

<link rel="stylesheet" href="css/mainstylesheet.css" />

This code tells the user agent that the link is to a style sheet and where it can find the link (css/mainstylesheet.css). The user agent will then deal with the link however it sees fit. You can, however, scope the use of the CSS contained in that style sheet with the media attribute:

<link rel="stylesheet" href="css/mainstylesheet.css" media="screen" />

In this example, only devices that will be displaying the content on a large screen will do anything with that style sheet. And where screen is concerned, that pretty much means a PC (Windows, Mac, Linux, etc.) and a web browser (Firefox, IE, and so on).

Adding a media Attribute to the @import Statement

If you are using the @import method for linking to a style sheet (perhaps to throw older, non-standards-friendly browsers such as Netscape 4 off the scent), you could use the following syntax:

<style type="text/css">     @import url("/files/includes/css-/files/includes/print.cssstylesheet.css") /files/includes/print.css; </style>

There is a small problem with this approach, however: IE versions 6 and earlier won’t deal with this syntax (at the time of this writing, IE 7 didn’t understand this construct either), so you’re probably going to have to use the previous method for linking wholesale to a CSS file.

Note: You can place the @import statement in a style block as shown in the example, or you can embed that @import statement in another style sheet that is already linked to the document, but the @import statement must be at the beginning of that style sheet, not after any other CSS selectors.

Adding the Media to Specific Selectors within a Style Sheet

Finally, you can embed some media-specific styles within another style sheet like so:

<style type="text/css">   body {     font-size: 62.5%;   }   h1 {     color: red;   }   h2 {     color: blue;   }   @media /files/includes/print.css {     h1 {       color: black;     }     h2 {       color: gray;     }   } </style>

Creating a Print Style Sheet

In our experience, the greatest use you’ll have for different media types is with /files/includes/print.cssed output. There are a few quirks to be aware of (and we’ll cover those), but it’s very well supported in general and can be put to great use.

We’ve mentioned the various techniques that you can use to link to a style sheet with different media. Our preference is to do the following:

  • Create a basic CSS file that contains generic visual styles that are understood by most browsers. Avoid CSS layout and anything that could be considered intermediate-to-advanced CSS. This CSS file is attached to the document using a link element but without specifying any media type whatsoever.
  • Create a second style sheet that is used for more advanced screen styles and use the @import statement embedded in the /files/includes/basic.css file to attach it. Netscape 4 won’t see this advanced file, but other newer browsers will.
  • Create a /files/includes/print.css-only style sheet and attach it using the link element with media="/files/includes/print.css".

Note: You should declare the /files/includes/print.css style sheet last (link to it even after any <style></style> block inside the HTML page). If you declare the /files/includes/print.css style sheet first, you could undo any values set there in the subsequent generic style sheets if they are not scoped for screen or some other medium.

Translating that English into markup, we get this in the document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head>     <title>Simple /files/includes/print.css test</title>     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />     <link rel="stylesheet" href="css//files/includes/basic.css" />     <link rel="stylesheet" href="css//files/includes/print.css.css" media="/files/includes/print.css"  /> </head>

and in the basic CSS file:

@import url("/files/includes/advanced.css");

What Do You Put in a Print CSS File?

There are not any real hard-and-fast rules about what should or shouldn’t go into a /files/includes/print.css CSS file. However, let’s take a moment to consider some of the characteristics of the /files/includes/print.cssed format. Keep in mind that in /files/includes/print.css you can’t do the following:

  • Click on navigation items to take you to another piece of paper
  • Conduct a search or carry out a calculation
  • Zoom in or out on a map or resize text using a text widget of some kind
  • “E-mail this story to a friend”
  • Scroll the page
  • Send feedback

What you can do with /files/includes/print.css CSS is almost the reverse of the previous list:

  • Hide all navigation elements that are no longer any use
  • Hide search facilities or other interactive form elements
  • Hide controls that affect on-screen display
  • Hide links that spawn some browser or application functionality

In fact, anything that you can click on or interact with on screen may need some kind of alternative treatment for /files/includes/print.css. Examples include hiding the element entirely or removing some display attribute that no longer works in the /files/includes/print.cssed format (for example, removing underlines in body text links).

Note: In most browsers, you do not need to be too concerned about dealing with background images that appear on screen; they are usually set not to /files/includes/print.css by /files/includes/default.css and, as such, are unlikely to need any special /files/includes/print.css-only treatment. One exception is Opera, which will /files/includes/print.css backgrounds out by /files/includes/default.css (or at least it does in versions 8 and 9 that we tested), but this can easily be unset in the File » TRA Print Options menu. If you have a sufficient number of Opera users, you might want to override background images for given elements, for example, body {background-image:none;}, so that users do not have to specify this for themselves—but it’s not a major consideration that you need to worry about.

One of the first things you should consider with a /files/includes/print.css layout is resetting any layout mechanisms you’ve used for the screen view. This involves removing floats, absolute positioning, padding, and margins.

Tips for Even Better Printed Pages

Our previous example showed a simple /files/includes/print.cssout that you can achieve by resetting certain CSS properties and redefining others. There is more that you can do to improve matters, though:

  • Use serif fonts. Because of the low resolution that monitors provide, and the fact that a large number of users do not have something like ClearType (www.microsoft.com/typography/cleartype/tuner/Step1.aspx) enabled, small-sized serif fonts often look poor on screen—there simply aren’t enough pixels available to render all the little flourishes (or serifs) at the ends of letters. It’s no mistake that a large number of web sites use sans-serif fonts (such as Verdana, Arial, and Helvetica) on screen; the lack of serifs makes them easier to render and thus easier to read. On screen. For the /files/includes/print.cssed version, though, you can quite easily use a serif font, such as Georgia or Times New Roman. Serif fonts provide extra shape to the letters and can often help distinguish among similar-looking characters; the serifs also create an implied horizontal line that’s supposed to aid readability.
  • If you’ve lost background images for /files/includes/print.css, you might be able to work around this by including an inline image that is hidden in the main style sheet (give it a unique id so that you can reference it) with a display:none but is made visible in your /files/includes/print.css CSS file using display:block or display:inline. The downside is that you are including an image that, for the vast majority of users, will not be seen but will still get downloaded to the client. If that’s something that concerns you (and it probably depends on how big the image is), you could use CSS-generated content to dynamically write in the image—for example, in the /files/includes/print.css style sheet, div.offer:after {content: "<img src='/files/includes/images/articles-css_styling_for_/files/includes/print.css_and_other_media-/files/includes/print.cssimage.gif' alt="Special offer" />"}. But remember that IE 7 and earlier won’t pay any attention to that code. Certainly, the former technique enjoys better support.
  • Bullet points missing? In the previous chapter, we suggested that applying background images was the best method for creating custom list item symbols. When you /files/includes/print.css them, though, the images won’t show. For that reason you should redefine the display for /files/includes/print.css so that the image is attached using list-style-image (or simply remove the custom bullet styles altogether and go with the basic styles that the browser would apply).
  • Provide special offers for /files/includes/print.cssouts. While the browser will, by /files/includes/default.css, /files/includes/print.css information such as the date, URL, and page number, you can add custom information for the /files/includes/print.cssed version. As an example, if on our travel site you found the perfect vacation and /files/includes/print.cssed out the details, you could include a /files/includes/print.css-only section on how to make a booking. This section might include a telephone number and a reference number, while the screen view would instead display a link to the e-commerce section of the site to make an online booking.

Things to Watch Out For

With a little care and attention, you can create web pages that perfectly suit the /files/includes/print.cssed medium. Yet be aware that there are some things you need to take into account.

Checking Your Page Width

If you have defined a width for your page using pixels, you will need to redefine that for /files/includes/print.css using a real-world measurement such as centimeters, millimeters, or inches. Be sure to allow for the fact that the /files/includes/print.csser your site visitor is using may not be able to /files/includes/print.css right up to the edges. If you take a US letter or A4 sized piece of paper, measure its width, then take off a couple of centimeters or a quarter inch from either side, that should give you a /files/includes/print.cssable page width.

Printing Errors with CSS Positioning

If you have reset all the positioning properties as suggested earlier in this chapter, you will probably not run into difficulties. However, be sure to try /files/includes/print.cssing a web page with a lot of content—a page that you would expect to run into several /files/includes/print.cssed pages—to make sure that the entire web page /files/includes/print.csss. Using floats and absolute position can affect the /files/includes/print.cssout, resulting in only the first page getting /files/includes/print.cssed. If this happens, double-check the CSS for the container of the content that is being “clipped” and ensure that you have set float:none and position:static.

Note: In case you’re wondering “What’s that static value? And why haven’t we heard about it before?” it’s because that’s the browser’s /files/includes/default.css positioning model. You would not normally need to set this yourself—we only have to do this to get around a known /files/includes/print.cssing problem.

Getting Feedback About Your “Funny Printouts”

Despite all your hard work, someone is bound to ask, “Why does your page not /files/includes/print.css out properly?” Many users expect that what they see on screen will be replicated in the /files/includes/print.cssout. Remember that you can use /files/includes/print.css CSS itself to address the issue (e.g., perhaps a block of text that reads “This page has been crafted for perfect /files/includes/print.cssing…” that is hidden on screen but set as display:block for the /files/includes/print.cssed version).

Advanced Print CSS Techniques

Hiding and showing or restyling content dependent on the medium is fairly straightforward stuff once you’ve grasped the basics. In this section, we’ll examine some more advanced features that introduce some extra dynamics into the usually static world of /files/includes/print.css. This is where browser support can get a little flakier, though, so be sure to treat these as nice-to-haves, rather than as essential features that must be available to all browsers.

Inserting URLS in Printed Pages

The great thing about reading a web page with links is that when you see an underlined phrase you can click on that link and immediately investigate another avenue.

With that page /files/includes/print.cssed out, you have no way of following that link, so you have a couple of choices:

  • Suppress the underline (or any other link styling, such as bold text) for /files/includes/print.css so that it doesn’t get in the way needlessly; there’s no point signifying a link that can’t be followed.
  • Choose the opposite route—instead of hiding the link styling, expand on it and dynamically create a /files/includes/print.cssed version of the web address (whatever is in that link’s href attribute).

The latter is definitely doable, but it requires some slightly advanced CSS (not supported by IE 7 or earlier) or a JavaScript solution.

Using Generated Content to Write Out the URL

Here is the basic CSS that does the job of writing out links on the page (be sure to add this only to the /files/includes/print.css CSS file):

a:after {     content: " (" attr(href) ") "; }

This code tells the browser to get the value of an attribute (the href attribute, as detailed in the parentheses) and then place that value in a string that begins and ends with parentheses. If you are familiar with JavaScript, it’s equivalent to

" (" + this.getAttribute('href') + ")"

but there is no concatenation symbol such as + or &. In this example HTML:

<h3> <a href="/book/bookDisplay.html?bID=10079"> Building Flickr Applications with PHP </a> </h3>

it would render on the /files/includes/print.cssed version like so:

Building Flickr Applications with PHP

Tip: You probably wouldn’t want every link on the page to get this treatment, so you may want to scope it by using a contextual selector, for example #bodycontent a:after {content: " (" attr(href) ") ";}.

When looking at a block of content, a long URL directly after the text can make it a little difficult to read, regardless of the benefit offered by having the reference there. Wouldn’t it be great if you could simply create a footnote from each link and just place a number after the link that references the footnote link? Well, you can thank Aaron Gustafson for devising a JavaScript technique that does just that, all ready for you to download and implement.

Selective Printing Using the DOM and CSS

One final advanced technique that you might like to consider is mixing together DOM scripting and CSS to create specific /files/includes/print.cssable areas of a page. An example of how this works is a FAQ page that contains many blocks of content. You might want to /files/includes/print.css only one section of that page; by using JavaScript you can dynamically toggle display attributes of different sections so that only the part you want /files/includes/print.cssed is shown—but without affecting the screen view.

This is a fairly involved technique, which is covered thoroughly (a chapter in its own right!) in another Apress book, Web Standards Creativity (February 2007), although you can also read about the technique online on my personal blog.

Style Sheets for Other Media Types

As we mentioned at the beginning of this chapter, the support for other media types is very spotty indeed, and what you can do with it is severely limited. We won’t explore all the various CSS property values that you can use with audio style sheets (it’s highly unlikely that such a discussion would be of use to most readers), but we’ll look at a few media types.

The Projection Media Type

Another media type that does have a modicum of support is projection. As far back as version 4, Opera has supported this type, but what does it do? Projection is intended for use with presentation versions of a web page; all browser toolbars and the like are removed, and the information is presented in full screen. A good example is S5, a web-page-based presentation format that CSS guru Eric Meyer devised, and which is used by many web standards advocates throughout the world. In Opera you trigger the Projection mode by choosing View » TRA Full Screen. Firefox and IE will not render the projection content when viewed in full-screen mode, so you have to ask yourself: What benefit can you get from using this?

The Aural Media Type

With the aural CSS properties, you should be able to control the pitch, speed, tone, and other attributes for speech-synthesized versions of the web page to great effect, but support for this is very much lacking. To date, we’ve only seen (or rather heard) one good application of this: a plug-in for Firefox called Firevox, which is definitely worth downloading and checking out to see what should be possible with this technology. You can find out more about the various CSS aural properties and values at the W3C (www.w3.org/TR/REC-CSS2/aural.html), or for a simpler example try the W3Schools introduction to this topic.

The Handheld Media Type

Another example of “great in theory, but almost useless in practice,” the handheld media type is perfect for specifying styles that can be used for a cell-phone-based browser, Blackberry, or similar device. However, the mobile market (phones in particular) are almost a law unto themselves and have devised various strategies for rendering web pages in the struggle to gain a competitive edge. At http://css-discuss.incutio.com/?page=HandheldStylesheets you’ll find a quotation that pretty much sums up the sorry state of handheld support:

Some current phones apply “screen” styles as well as “handheld” styles, others ignore both, and in some cases the phone carrier runs pages through a proxy that strips styles out even if the phone could recognize them, so it’s a crapshoot figuring out what will get applied.

So, all bets are off! It’s good to be aware that the media type exists and what its intended use is, but, seriously, don’t waste effort in trying to design a slick interface for a given handheld device and expect it to honor only your handheld styles and ignore the screen styles—and certainly don’t expect the next handheld to do the same.

The All Media Type

The all media type is pretty much superfluous. If you want a style sheet to be rendered on all devices, you may just as well not set a media type at all and let the device, browser, or user agent work it out for itself.


The ability to create specific style sheets for different media seems, on the face of it, to be a very powerful tool. However, in practice you are limited in what you can do. It seems a shame to end on a sour note, but we hope the things that you can do with the /files/includes/print.css medium more than make up for the rest. Now, if only the mobile market could decide on a standard and stick with it, we could do great things with those devices just as we can with the /files/includes/print.cssed medium. Well, we can hope—and a good place to start is with Blue Flavor’s presentation on mobile web design.

Excerpted from “Pro CSS Techniques” by Jeff Croft, Ian Lloyd, and Dan Rubin. Copyright Ian Lloyd 2006. Used with permission of Apress, Inc.

Related Topics: CSS, DOM

Ian Lloyd founded Accessify.com, a web accessibility site, back in 2002 and has been a member of the Web Standards Project since 2003, where he is part of the Accessibility Task Force. He has written or co-authored a number of books on the topic of standards-based web design/development and lives in Swindon, UK, a place best known for its ‘Magic Roundabout‘ and Doctor Who’s Billie Piper. (It’s not all bad, though.)