4

Why is it that browsers do not provide a mecanism to set the printing defaults regarding headers and footers from within the app?

Web apps are fully fledged apps nowadays, and modern browsers are capable of sending a very well formatted page to a printer (or even download it as a PDF), but web apps cannot rely on this method because browsers don't allow them to control the metadata completely.

Current possibilities don't allow websites to store the printing settings along with the report or file on the server.

Each browser provides it's own mandatory dialog form to set printing settings that could be replaced when needed by a more convenient experience: in-app options, adapted to the use case, cloud-persistent and consistent along different browsers.

The options that are currently available are:

  1. Delegating part of the work on the user (i.e., having him/her change the metadata options and paper size/orientation themselves).
  2. Using other methods that can quickly become too expensive and complicated, like generating PDF's on the server for the user to download.

Opting for number 1 is not always our decision. As professional web developers, the final users are usually not our direct clients, but our client's target audience. Also, we would be forcing the final user to do extra work. Experience says that it wouldn't be done and reports will be printed with the default settings of the browser, usually with headers and footers that the user don't really want (and the associated paper waste if he/she decides to print it againg without them).

Option 2 --generating server side PDF's-- is becoming less of an option every day. Modern web apps are heavy users of javascript, and reports benefit from excellent plotting libraries made with JS that can generate charts in HTML canvas elements that could be printed right away if we weren't using this "do it all over again on the server" approach. The resulting reports never look the same, and programmers have to maintain two versions of every report.
Moreover, generating PDF's on the server can be really slow and resource consuming.

So, is there a compelling reason why browsers programmers opted not to support this kind of customization?

closed as primarily opinion-based by gnat, Blrfl, user40980, GrandmasterB, Bart van Ingen Schenau Aug 12 '14 at 20:19

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I might understand headers and footers, but why do you want to mess with my default printer settings? Who knows best what kind of paper I have in my printer's tray, you or me? – Bart van Ingen Schenau Aug 12 '14 at 13:08
  • "avoid asking subjective questions where … your question is just a rant in disguise: “______ sucks, am I right?”" (help center) See meta.programmers.stackexchange.com/questions/6483/… – gnat Aug 12 '14 at 13:11
  • I didn't think about the rant side of the question. It's true that it frustrates me, but I will edit it and I'm sure that it will became a very valid question. – Sebastián Grignoli Aug 12 '14 at 13:34
  • @BartvanIngenSchenau It's not that the web app should change your general settings, just those for the current print. Why? Because sometimes the browser don't give you enough control and you really need it. Consider a website that allows you to save the selected paper size along with the file you're editing, like Word does. – Sebastián Grignoli Aug 12 '14 at 13:44
  • 1
    Word was built from square one to work within a particular page configuration. Forcing a document into that is beyond the scope of what HTML was designed to do. – Blrfl Aug 12 '14 at 13:57
4

There is a definite tension between designs appropriate for interactive use and those that look good on the printed page. All of the interactive functions that have evolved into HTML pages/apps (e.g. forms, buttons, navigational controls, dynamic AJAX data loads, and interactivity) do not rest well on a static piece of paper. The print-outs of many web pages positively screams "I am a printed web page! I was not designed to be printed!"

But that doesn't mean it can't work. Most of the sites that really care about printed output have a separate printer icon that generates a "designed to be printed page." That requires some extra programming, but is generally manageable with templated output.

Modern CSS has an @media that designates what output realm a CSS rule apples to. Different CSS style sheets can be imported for screen and print:

<link rel="stylesheet" type="text/css" href="style.css" media="screen,print">
<link rel="stylesheet" type="text/css" href="paper.css" media="print">

Or you can designate rules directly inside a stylesheet, like so:

@media screen {
    body { 
        background-color: green; 
        margin: 20px;
    }
    p {
        font-family: verdana,sans-serif;
        font-size: 14px;
    }
}

@media print {

    @page {
        size: letter portrait;
        margin: 0mm;
    }
    body { 
        background-color: white; 
        margin: 1in;
    }
    p {
        font-family: sans-serif;
        font-size: 20px;
        color: black;
    }
}

Note the @page selector sets page size, orientation, and margins. There are specific mechanisms for handling first pages, left pages, and right pages; for managing pagination (where page breaks occur, how widows and orphans are managed, etc.) On some browsers (Chrome and Opera e.g., and possibly Firefox, setting the page margin to 0 will eliminate the annoying automatically supplied headers and footers you mentioned. But like all things Web, this is browser-specific. On some browsers (looking at you, IE!), the user may need to turn off those embellishments when printing. Microsoft products also seem to obey some Microsoft-specific page controls such as mso-header-margin, mso-footer-margin, and mso-paper-source which might help you squelch undesirable extras.

So, long story short, good browser support for printing is feasible and available. CSS's page-oriented design features don't have 100% the precision of a word processing or page layout format, but they're pretty close. They should be more commonly used.

Here is the relevant CSS3 specification, a good quick overview of the @page rule, and a good article on how to set up a print style sheet.

  • So... it turns out that it's all already customizable except headers and footers (at least in a consistent way), right? – Sebastián Grignoli Aug 12 '14 at 14:46
  • More on the subject of margins: stackoverflow.com/a/2780518/290221 (info on how different browsers behave) – Sebastián Grignoli Aug 12 '14 at 14:49
  • Yes, most of the things you wanted (control of the page shape, orientation, etc.) and need (pagination) are customizable via CSS. Chrome and Opera handle those specs very nicely; Firefox and IE, less so (if only because it's harder to squelch unwanted/unneeded headers/footers). It might be possible to create shims to hide IE/Firefox headers/footers (e.g. white boxes that overlay them), though haven't seen pre-made versions. – Jonathan Eunice Aug 12 '14 at 17:51
  • Also, a helpful trick: as an alternative to generating a new window with printable content, some of my apps simply delete all the UI/interactive controls, or make them invisible. That's a single jQuery statement, and it leaves a page that is essentially pure content--thus ready for printing. – Jonathan Eunice Aug 12 '14 at 17:54
  • I believe you can also set them to display:none in the printed media stylesheet. – Sebastián Grignoli Aug 12 '14 at 19:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.