W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Printing and background colors/images

From: イアンフェッティ <ifette@google.com>
Date: Tue, 22 Feb 2011 09:17:22 -0800
Message-ID: <AANLkTi=boKkDKZ=_u3t5bxS0U27-x6Gb7ff7qhq=+mmw@mail.gmail.com>
To: www-style@w3.org
Summary: Want authors to be able to specify whether backgrounds should be

While it is possible to specify background colors and images for many
elements, at present these backgrounds are not printed by default in
browsers. Though some browsers offer a setting to print backgrounds, it's
usually buried under a dialog no one finds ("page settings"), and I'm not at
all convinced that a user would realize that a page using <span
style="background-color:yellow">blah</span> requires that setting to print
correctly. I was in the middle of adding this option to Chrome when I
realized that even after adding this option, we probably would not have
solved the problem we originally wanted to solve -- letting something like
google docs actually print a document with highlighting, without requiring
them to create a PDF just so that highlighted text would print.

In talking with other people on Chrome team, we managed to brainstorm a few
options, though I am not set on any of them and would really appreciate
feedback on which of these is preferable, or any other options as well.

1. Just print all backgrounds. Pros: enables the use case. Cons: All sorts
of pages with white text on black background are needlessly going to waste a
ton of ink. Not likely to fly.

2. Print backgrounds only if explicitly specified inside of a @media print{}
block. Pros: Relatively explicit in terms of author intent, wouldn't require
any major spec changes. Cons: Leads to some strange cases, e.g. if I specify
".highlight {background-color: yellow}" for highlighted text, I also have to
explicitly specify "@media print { .highlight { background-color: yellow} }"
? Also, in WebKit, and presumably other browsers, this may lead to
implementation difficulty as currently, all the styles are processed and
then applied, and no state is kept as to where the style came from. When
it's time to paint, the style is overridden if the option to print
background colors is in its default state (false), and so this would require
carrying around extra state for each resultant style to track if it came
from a @media print{} block, which is both a bit heavy, and hacky. It could
work though.

3. Add an explicit new property, like print-background. Pros: Explicit,
wouldn't cause unexpected behaviour by starting to print a bunch of
backgrounds that users didn't intend to print. Also relatively
straight-forward implementation wise. Easy to understand. Cons: This
property would be meaningless outside of a print media context, so
semantically it feels a bit odd.

I'm not in love with any of the options, but I really want to get
/something/ in place. The current status-quo, while perhaps looking nice
from a semantic/spec point of view, is essentially useless for web authors
as virtually no end-user ever has printing of background colors and images
enabled, and from a browser standpoint, there's no good way for us to divine
if a web author actually intended a background to be printed, or if the
author didn't ever think about how something would look on paper, hence
we've not been willing to enable that option by default.

Received on Tuesday, 22 February 2011 17:17:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC