CSS Printing Extensions

Status of this document

This document is a W3C Working Draft produced by the working group on Cascading Style Sheets and Formatting Properties as a part of the Style Sheets Activity. It is published for review by W3C members and other interested parties. Comments from non-members should be sent to www-style@w3.org. There is general consensus in the working group that the functionality described in this specification improves printing from the web. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C technical reports can be found at http://www.w3.org/pub/WWW/TR.

Abstract

This specification describes a set of extensions to Cascading Style Sheets (CSS) to better support printing from the Web. These extensions let style sheets express page breaks, page boxes, and media dependencies. Also, a way to point to an alternate print document is described. This is a first pass at a rather formidable problem, but one which can yield good results in the near term.

Background

We have taken a very specific approach to our goal of improving Internet Printing. To understand this path, and why the current lamentable state of printing on the Web is becoming increasingly unsatisfactory, it is necessary to reflect on current trends, the objectives of Web publishers, and the desires of users. This has been discussed at length in other documents, so only a brief summary will be presented here.

• No one has yet invented a cheaper, more reliable, more portable, more convenient, or more universally acceptable "reader" of information than the printed page. Modern printers are getting much cheaper while overall quality is rising dramatically, especially in desktop color printers.
• There are many reasons why printing is still popular. Chief among these for end users are issues concerning convenience, comfort, and psychology. People want to print.
• Contrary to conventional wisdom, the advent of the Web is very likely to cause an overall increase in printing rather than its demise. New applications, access to huge quantities of unfamiliar and transient information, and intranet and Internet business applications will continue to push print usage up. In the near future, nearly all printing will be from some type of Web technology.
• Web printing is fundamentally different from desktop PC printing. The WYSIWYG paradigm is broken, users are rarely familiar with the content and are generally unable to effect changes in a document to improve its printed appearance. In a typical PC application such as word processing, the output medium of choice has always been the printed page, with the screen serving as a reasonable facsimile. The situation with Web publishing is just the opposite.
• The screen is a very different type of output medium from paper. It is unreasonable to expect information formatted for one medium to look optimal on the other medium. Screens are smaller, more dynamic, and more difficult to read. They may be multimedia and even interactive. Paper is more dense, slower, and completely static. Print resolution is usually much higher than screen resolution. As just one example, it has been shown that sans serif fonts are easier to read on screen, while fonts with serifs are easier to read on paper.
• One aspect of the Web involves competition and it is very important for Web publishers to not only attract a readers attention, but to keep them interested and get them to return. Web pages must not only be functional, but interesting, esthetically appealing, and eye catching. Consequently, the best Web pages are very active, involving many forms of multimedia.
• On the other hand, printed pages are completely static by nature. While they may contain both text, graphics, and images, they may not contain video, animation, or sound.
• The best web pages for screen display make the worst web pages for print. Therefore, the most active web pages must be converted to static pages prior to printing. If this is not done just right, the intent of the author may be distorted and critical information may be lost. If the information is not too significant, then perhaps this can be done automatically by the user agent.
• Where the best output for both media is a necessity, the author must provide two versions of the content: an active version for screen display and a separate static version for printing. While this is definitely more work, many publishers on the Web are willing to go to whatever lengths are necessary to attract and keep customers. Perhaps future authoring tools will allow for the simultaneous production of both pages. In any case, a simple and convenient method for the user to find the print version is mandatory.
• The key to high quality Web printing is at the point of authorship. Much of the appeal of the printed page is in the author's composition, choice of fonts and images, use of color, etc. The User Agent can do a much better job of rendering a page for printing with some helpful style hints from the author.
• The vast majority of all Web publishing will be in the de facto standard, HTML. Most publishers will want to use this language to its fullest extent and only call on other methods and applications when it just will not do the job. HTML will not develop into a page description language, and publishers that need precise layout control will need a simple and convenient method of invoking other applications.
• Premium Web sites will want to use the Alternate Print Document to deliver to their customers the best possible screen and print experiences. However, there are many different types of sites and page authors, each with their own needs and goals. We believe that the majority of HTML authors will not wish to maintain separate screen and print versions of their documents and will be happy if they can apply different styles to the screen and printer using the same source.
• Printing by itself and multimedia by itself are two difficult and highly developed disciplines already. The intersection of these two features does not lend itself to a single, universal solution. Rather a range of solutions is required to meet the various needs of many types of Web publishers.

This document is intended to be a first pass at solving the Web printing problems discussed above. The described CSS extensions will enhance printing from the Web, but will not make HTML/CSS into a page description language. We believe, however, that this specification is extensible and a good base from which to proceed.

Scope and Terminology

This specification describes a set of extensions to Cascading Style Sheets (CSS) [1]. These extensions let style sheets express:

• page breaks: one can specify that there should be a page break before or after HTML elements, for example before all 'H1' elements.
• page boxes: the style sheet can set page boxed that describe the printable area on a page. Page boxed may be different on left and right pages. Also, crop and cross marks can be added to pages.
• media dependencies: one can specify that a section of a style sheet applies only to a certain media type, for example PRINT or SCREEN. Another [forthcoming] W3C Working Draft, WD-style [2], lists the various media types. Currently, the list includes: PRINT, SCREEN, PROJECTOR, BRAILLE and AURAL.

In this specification, the term page refers to a rectangular area into which the formatting process flows the content of a document. The scope of this specification is to extend style sheets to aid UAs when formatting documents into pages. Thereafter, the UA must transfer the formatted pages onto sheets of paper, but that transformation is outside the scope of this specification. For example, this specification does not address:

• sheet tray selection
• single- vs. double-sided printing
• "n-up", where multiple pages are printed next to each other on the same sheet
• rearranging pages into signatures (a signature is a group of pages printed on a sheet, which when folded and trimmed will appear in their proper sequence)

Often, information about the sheet size is not available to the UA. For example, a document may be "printed" to a file, or the user may perform "n-up" operations outside the UA. Still, the UA will need to target a certain size and orientation when printing, and this is known as the target. The user will typically set set the target size and orientation in the Print dialogue box of the UA. There will often, but not always, be a correlation between the target size and the sheet size. The figure below shows how information flows between the HTML document, the page and the sheet.

This specification is based on the CSS1 syntax, formatting model and terminology. It is possible for other languages, e.g. scripts, to access the described functionality if a mapping to the full CSS1 syntax has been defined.

Page breaks

Two new properties indicate where the UA should break pages, and on what page (left or right) the subsequent content should resume. These properties have been designed to support the PRINT medium, but can also be applied to other paged media, for example PROJECTOR.

'page-break-before'

Value: auto | always | left | right
Initial: auto
Applies to: block-level elements outside of tables
Inherited: no
Percentage values: N/A

The values are:

auto

do a page break before the element only if necessary

always

always do a page break before the element

left

do one or two page breaks before the element until a blank left page is reached

right

do one or two page breaks before the element until a blank right page is reached

As an example, a page break may be inserted in the document before all H1 elements:

  <STYLE>
    H1 { page-break-before: always }
  </STYLE>
  ...
  <H1 CLASS=chapter>
  ...

If there are conflicts between this property and the 'page-break-after' value on the next element (as formatted on the canvas), the value that results in the largest number of page breaks will be used.

Note: a way to suppress page breaks before an element is under discussion, but the syntax is not yet defined.

'page-break-after'

Value: auto | always | left | right
Initial: auto
Applies to: block-level elements outside of tables
Inherited: no
Percentage values: N/A

The values are:

auto

do a page break after the element only if necessary

always

always do a page break after the element

left

do one or two page breaks after the element until a blank left page is reached

right

do one or two page breaks after the element until a blank right page is reached

As an example, a hard page break may be inserted in the document with the BR tag as follows:

  <STYLE>
    BR.page { page-break-after: always }
  </STYLE>
  ...
  <BR CLASS=page>
  ...

If there are conflicts between this property and the 'page-break-before' value on the previous element (as formatted on the canvas), the value that results in the largest number of page breaks will be used.

Note: a way to suppress page breaks after an element is under discussion, but the syntax is not yet defined.

Page boxes

Normally, CSS declarations are attached to HTML elements. For example, to set the font size of a paragraph, a 'font-size' declaration is attached to a 'P' element. HTML has no element that corresponds to a page -- in fact, HTML has no notion of a page. The at-rule extension mechanism of CSS1 is therefore used to select the page:

   @page { margin: 2cm }

Declarations inside the curly braces of the at-rule apply to the pages of a document. These declarations are said to be in the page context, and they describe a page box into which the elements of the document are flowed. The page box is similar to the boxes that surround each HTML element (see the formatting model of CSS1 for more information) and some of the same properties apply:

• margin-top
• margin-right
• margin-bottom
• margin-left
• margin

In addition, the page context allows the 'size' property to set the size of the page box and the 'marks' property to set crop and cross marks. These two properties are described below.

The diagram below shows the relationhips between the sheet, page box and margin properties.

   ____________________________
  |                            |<- sheet
  |   ______________________   |
  |  |    A                 |  |
  |  |    ______________    |<-+-- page box
  |  |   |              |   |  |
  |  | D |              | B |  |
  |  |   |              |   |  |
  |  |   |              |<-----+-- page box minus margins
  |  |   |              |   |  |
  |  |   |              |   |  |
  |  |   |              |   |  |
  |  |   |______________|   |  |   A: margin-top
  |  |    C                 |  |   B: margin-right
  |  |______________________|  |   C: margin-bottom
  |                            |   D: margin-left
  |____________________________|

Note that while the margins are outside the boxes surrounding an HTML element, they are inside the page boxes. In the future, the border and padding properties may also be supported.)

The page context has no notion of fonts so 'em' and 'ex' units are not allowed. Percentage values on the margin properties are relative to the page box. All other units associated with the respective CSS1 properties are allowed.

Due to negative margin values (either on the page box or on elements) or absolute positioning [3] content may end up outside the page box, but this content may be cut -- by the UA, by the printer or ultimately by the paper cutter.

New properties in the page context

size

Value: <length>{1,2} | auto | portrait | landscape
Initial: auto
Applies to: page context
Inherited: N/A
Percentage values: N/A

This property describes the size and orientation of a page box. Page boxes can be either absolute or relative. Typically, absolute page boxes are used when it is important to achieve very accurate formatting, while relative page boxes are used for scalable presentations that make optimal use of the target size.

Absolute page boxes are described with one or two length values:

  @page {
    size: 8.5in 11in;  /* width height */
  }

The above example set the width of the page box to be 8.5in and the height to be 11in. If only one length value is specified, it sets both the width and height of the page box. Since the page box has no "parent" percentage values are not allowed on the 'size' property.

The page box in the above example will need a target size of 8.5"x11" or bigger to be printed. If the page box does not fit the target, the UA may choose to:

• rotate the page box 90° if this will make the page box fit the target
• scale the page to fit the target

The UA should consult the user before performing these operations.

When the page box is smaller than the target size, the UA is free to place the page box anywhere on the sheet. However, it is recommended that the page box is centered on the sheet since this will align double-sided pages and avoid accidental loss of information that is printed near the edge of the sheet.

Typically, 8.5"x11" sheet size will be available in North America, while printers in other parts of the world are more likely to have the A4 sheet size available.

For most printouts, document scalability (i.e. fitting available sheet sizes) is more important than achieving exact dimensions and relative page boxes allow style sheet designers to easily achieve this. Three keyword values describe relative page boxes:

auto

the page box will be set to the target's size and orientatation. This is the initial value of the property.

  @page {
    size: auto;
    margin: 10%;
  }

In the above example, the outer edges of the page box will align with the target. (Since 'auto' is the initial value on 'size', it is normally not necessary to set this value.) The percentage value on the 'margin' property is relative to the target size so if the target is 21.0cm x 29.7cm (a.k.a. A4), the margins are 2.10cm and 2.97cm.

landscape

the page box will have the same size as the target, and the normal direction of print occurs across the largest dimension of the target. Thus, the target orientation will be ignored.

portrait

the page box will have the same size as the target, and the normal direction of print occurs across the shortest dimension of the target. Thus, the target orientation will be ignored.

marks

Value: crop || cross | none
Initial: none
Applies to: page context
Inherited: N/A
Percentage values: N/A

In high-quality printing, various marks are often added outside the page box. Crop marks indicate where the page should be cut and cross marks (also known as register marks or registration marks) are used to align sheets. This property describes what marks should be printed on the page outside the outer edges of the page box.

Marks are only visible on absolute page boxes. In relative page boxes the page box will be aligned with the target and the marks will be outside the printable area.

The size, style and position of cross marks is UA dependent.

Pseudo-class page boxes

When printing double-sided documents, the page box on left and right pages should be different. This can be expressed through the pseudo-class mechanism from CSS1:

  @page :left {
    margin-left: 4cm;
    margin-right: 3cm;
  }

  @page :right {
    margin-left: 3cm;
    margin-right: 4cm;
  }

All pages are automatically classified into either 'left' or 'right' pseudo-class. Whether the first page is 'left' or 'right' depends on the major writing direction of the document and is outside the scope of this document. But note that you can use a page break before e.g. the 'HTML' element to force a left or right page.

More named paged (e.g. first) could be added in the future, and style sheet designers could possibly add their own names.

Adding declarations to the left or right pseudo-class does not influence whether the document comes out of the printer double- or single-sided (which is outside the scope of this specification). If different declarations have been given for left and right pages, these declarations will be honored even if the printer only prints single-sided. Thereafter, the intended design can be achieved by e.g. copying the single-sided sheets onto double-side sheets.

Cascading in the page context

Declarations in the page context cascade just like normal CSS1 declarations:

  @page {
    margin-left: 3cm;
  }

  @page :left {
    margin-left: 4cm;
  }

Due to the higher specificity of the pseudo-class selector, the left margin on left pages will be '4cm' and all other pages (i.e. the right pages) will have a left margin of '3cm'.

Media Dependent Style Sheets

Different output media can often take advantage of the same properties. For example, the 'font-size' property is useful both for SCREEN and PRINT media. However, the two media types are different enough to require different values on the common property; a document will typically need a larger font on a computer screen than on paper. For this reason, it's necessary to express that a style sheet -- or a section of a style sheet -- applies to certain media types.

There are two ways to do this:

• WD-style specifies how to use the MEDIA attribute on the LINK element to label style sheets:

    <LINK REL=STYLESHEET TYPE="text/css" MEDIA=PRINT HREF=foo>
  

• This specification adds "@media" at-rule to declare media types in the style sheet itself:

    @media print {
      /* style sheet "foo" goes here */
    }
  

Due to the same media type value, the two examples above are semantically equivalent.

In addition, the '@media' construct allows style sheet rules for various media in the same style sheet:

  @media print {
    BODY { font-size: 10pt }
  }
  @media screen {
    BODY { font-size: 12pt }
  }
  @media screen, print {
    BODY { line-height: 1.2 }
  }

Any valid MEDIA attribute value is valid on '@media'.

Alternate Print Document

The author of a document may want to specify an alternate method of rendering the document when the Print function is selected in the UA. A new value ALTERNATE is proposed for the REL attribute of the LINK element. This extension allows the author to prepare a separate print version of the document and to make it easily available to the user in a consistent manner.

Consider this example:

<HEAD>
<TITLE>Print me!</TITLE>
<LINK REL=ALTERNATE MEDIA=PRINT HREF="doc.ps" TYPE="application/postscript">
</HEAD>

In the above example, an alternate document that has been specifically designed for printing is made available through the LINK element. This document is automatically printed when the user selects the Print function in the UA. A further dialog may be presented to the user, but it is not required and is UA-dependent. If this document is automatically printed as a part of a greater collection or in a situation where the screen version is not rendered, then the first LINK statement containing an alternate document for the right MEDIA type in a known format will be used.

As the example above shows: the alternate document does not have to be in HTML. If the UA understands other MIME types, these may be specified. In such cases, an application or a reader may be invoked, the alternate document printed, and the user returned to the UA context to continue browsing.

Future Extensions

The following is a short list of where we expect to see additional work. Some of the challenges that we have discussed are briefly outlined.

• Multi-column Properties.
• Additional Page Properties. Documents might contain multiple sections, each with a different page orientation, headers/footers, etc. How elements span pages should be better controlled with widow/orphan control and keep together type properties. Additional formatting properties such as vertical page alignment and font kerning.
• Media Dependent Elements. It would be much easier for many users if a separate style sheet did not have to be maintained for each possible output medium. This would also support inline styles. Can they be merged so that a media property is associated with each element or style sheet property? What about properties that apply to more than one element? How do the various media cascade?
• Collections of Pages. The author may define a set of pages that may be logically printed together, e.g. a catalog or a chapter of a book. How does a user discover that the author has provided this? Is there a uniform UI that is presented? Can collections contain other collections? To what level? Are page relationships defined from a table of contents type of page or on each page itself? What if a page belongs to more than one collection? How can print collections be reconciled with other planned site navigation tools? Do collections have other uses besides printing, e.g. off line reading?
• Headers and Footers. How can those provided by the page author be reconciled with those desired by the user? What about site wide headers and footers, logos, and watermarks? Should all information be propagated even when redundant? Are headers a type of decoration or style? Is it proper to have headers and footers appear in style sheets? What if they have content in addition to format, e.g. a company confidential message as well as page number location? Is there a collection heading that has priority if the page is printed as part of an author defined set?
• Footnotes. How are footnotes specified within a page? Should we have a separate method for those at the end of a page as well as those at the end of a section? Can the user elect to have end of page footnotes printed at the end of the section anyway? How are footnotes presented on screen? As a pop-up? Can links to other HTML pages automatically be treated as footnotes?
• Environment Dependent Styles. Can the UA environment automatically pick an appropriate style? If a high resolution color screen is used, can it retrieve different images than a low resolution monochrome screen? Should high resolution printers retrieve a higher resolution image for printing? What if more than one printer is available? How does the UA describe the highest quality available for the various printers? Can certain display devices be paginated, thus presenting headers, footers, etc.
• Finishing Properties. These are the properties associated with a page to be printed that are required to meet the author's or user's printing requirements - rendering options, stapling or binding, impositions, delivery, accounting, media type or grade, form name, number of copies, etc. Especially useful in third party printing, shared printers, and intranet print shops. How are these attached to a document to be printed? Can portions be overridden? What about the security of the accounting information. Can they be divided into author and user fields, supplied at different points?

Acknowledgments

This document is a result of the efforts of the W3C's Working Group on CSS&FP. The following people have contributed to this document: Bert Bos, Sylvan Butler, Steve Byrne, Dan Connolly, Todd Fahrner, Phil Karlton, Chris Lilley, Roberta MacMillan, Murray Maloney, Lou Montulli, Jean Paoli, Dave Raggett, Todd Roshak, David Singer, Mandira Virmani, Mike Wexler, Chris Wilson and Stephen Zilles.

References

[1] Cascading Style Sheets, level 1, W3C Recommendation, http://www.w3.org/pub/WWW/TR/REC-CSS1

[2] WD-style, a forthcoming W3C Working Draft

[3] WD-positioning, http://www.w3.org/pub/WWW/TR/WD-positioning