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

[css3-gcpm] Printing backgrounds (thread reboot)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 15 Aug 2011 20:00:50 -0700
Message-ID: <CAAWBYDCPRbF20ZzfDb+g0ZMEH0Njiy75RBScDRgGp-Cvy6OLTg@mail.gmail.com>
To: www-style list <www-style@w3.org>
In the interest of readability, I'm rebooting the background-print
thread, so I can summarize the options presented so far and make it
easier to evaluate and eventually decide on the issue.

To start, the issue is that non-white backgrounds are the same cost as
white backgrounds on a computer screen, but are much more expensive
when printed.  Most webpages aren't designed with printing in mind,
and thus use far more non-white backgrounds than would be prudent in a
printed page.  To help users, most (all?) browsers automatically
suppress backgrounds when the user prints a page (and tweaks the text
colors as well, to maintain adequate contrast).  (It's theoretically
possible for browsers to do more than this, like suppressing
box-shadow, but no one does so far.)

Some browsers offer users the option to print backgrounds when they're
important, but this option is almost always hidden pretty deeply in
the print UI.  Chrome doesn't offer an option at all.

Webkit is interested in finding some way for authors to provide a hint
to the browser that they've thought about printing, and the
backgrounds they've set are significant and should be printed.

Whatever way is settled on, this should *NOT* take away the user's
ability to still suppress backgrounds when they choose (or, for that
matter, print all backgrounds when they choose).  It should just be a
hint for the default behavior, absent any user choice to the contrary.

Here are the options that have been brought up so far, along with my commentary:

(1) Honor any style present in a print stylesheet.

This doesn't work because the default media of a stylesheet is "all",
which means that it's a print stylesheet.  Thus, this wouldn't match
current behavior.


(2) Honor any style present in a stylesheet that is specifically
media='print' (or in an equivalent @media block)

This seems hacky, as we don't otherwise attach meaning to the precise
way you phrase the media query.  This is similar to how Opera handles
full-screen styles (if a media=projection stylesheet is present, use
it; otherwise, act like you match 'screen'). Two browser vendors have
specifically opposed this.


(3) Honor !important backgrounds

In other words, the user's preferences would be "don't print
backgrounds", "print all backgrounds", and "print !important
backgrounds" (with the last being the default)

I'm not sure how compatible this would be.  People use !important for
a lot of reasons, so it may be a pretty noisy signal, and not
something you want to rely on by default.


(4) Create a new property controlling this

Same as (3), but the last option becomes "print backgrounds on
elements with this property set".

This has the advantage that, as something new, it won't be noisy (at
least at first).

Possible ideas for syntax:

printer-friendly-colors: _auto_ | avoid
printer-color-adjust: _auto_ | avoid
printer-colors: _auto_ | exact

This idea also has a few variants:

(4a) Limit it to applying to the root element only.  Luke Macpherson
offered a use-case for it being useful per-element, but I think this
is relatively minor, and I wouldn't cry if we decided against it.

(4b) Expose this as a descriptor on the @page rule, instead of as a
normal property.  I'm not opposed to this, but it didn't seem popular
when it was briefly brought up in the previous discussions.  It seems
potentially useful, since I can easily imagine a printed book having
some pages where the backgrounds are important, but the rest where it
isn't.

(4c) Make this property somewhat more general (suggested by Mikko
Rantalainen) so you can specify a rendering intent in terms of color
profiles (similar to the sVG <color-profile> element).  I think color
profiles are a more general case that applies to *everything* on the
page, including text colors, <img> elements, etc., and so it shouldn't
be mixed into the semantic we're trying to express here.


So, my preference is (4), possibly with (4a) or (4b) instead.  Thoughts?

~TJ
Received on Tuesday, 16 August 2011 03:01:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT