Last Comment Bug 381466 - enable background printing on pages with print stylesheet
: enable background printing on pages with print stylesheet
Status: ASSIGNED
:
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: unspecified
: All All
: -- normal with 6 votes (vote)
: mozilla1.9alpha8
Assigned To: fantasai
:
Mentors:
http://fantasai.inkedblade.net/style/...
: 322008 (view as bug list)
Depends on:
Blocks: 388246
  Show dependency treegraph
 
Reported: 2007-05-21 11:36 PDT by fantasai
Modified: 2011-12-20 06:25 PST (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
tests (zip) (3.79 KB, application/zip)
2007-07-13 23:05 PDT, fantasai
no flags Details
patch (28.62 KB, patch)
2007-07-13 23:06 PDT, fantasai
no flags Details | Diff | Review
sample problem page (9.49 KB, text/html)
2007-07-19 21:28 PDT, Smokey Ardisson (offline for a while; not following bugs - do not email)
no flags Details
patch v2 (22.78 KB, patch)
2007-07-20 17:35 PDT, fantasai
kherron+mozilla: review+
dbaron: superreview-
Details | Diff | Review

Description fantasai 2007-05-21 11:36:03 PDT
Overview:

  The print/don't print backgrounds option is designed to save printer ink
  and avoid printing e.g. sites with black backgrounds and white text as
  ink-coated pages. However, for sites that are primarily black text on a
  white background, it also disables backgrounds used to accent and
  differentiate content (for example, light gray backgrounds on every other
  table row). Printed output from such sites would often look much more
  polished, and be easier to scan and read, if background printing were
  enabled.

Authoring Practices to Consider:

  Print style sheets that create an appropriate presentation for printed
  content are becoming more common. At the same time, some sites are starting
  to work around our default no-background-printing setting by using various
  tricks with e.g. borders and positioning. This abuses HTML+CSS. It also
  undermines our don't-print-backgrounds pref, which on these sites no longer
  functions properly for those who really want to save ink. I don't want
  that trend to continue.

Proposed Solution:

  One simply way to solve this problem would be to give the pref an auto
  state in which we enable background printing for sites that provide a
  stylesheet explicitly targetted at 'print' media. (This is similar to the
  way Opera turns off its handheld adaptation heuristics for sites that
  explicitly provide a 'handheld' stylesheet.)

Additional Information:

  I'm filing this on behalf of HP. They're a bit frustrated with this aspect
  of print output on some of their website projects.
Comment 1 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-05-21 11:40:41 PDT
It seems like you'd either:
 * need to come up with sensible UI to represent the tri-state pref, or
 * remove one of the existing states (probably the "never print backgrounds" state).
Comment 2 fantasai 2007-05-21 13:37:23 PDT
Yeah, I'd have to check with a UI guru on the prefs UI. But even if we remove
one of the existing states for Firefox, we might want to keep it in the back
end for other applications.
Comment 3 Melinda Grant 2007-05-21 13:52:40 PDT
The human factors engineers at HP suggest something like the following UI:
     Print backgrounds:
     _ Always (or Yes)
     _ Only backgrounds designed for printing
     _ Never (or No)

(They suggest losing the parenthetical 'colors and images' because this is confusing to most naive users.)

HP would propose that 'Only backgrounds designed for printing' should be the default setting.
Comment 4 fantasai 2007-07-12 19:50:56 PDT
Maybe
  Print backgrounds for: All pages
                         Printer-friendly pages
                         No pages
?
Comment 5 fantasai 2007-07-13 23:05:29 PDT
Created attachment 272289 [details]
tests (zip)
Comment 6 fantasai 2007-07-13 23:06:39 PDT
Created attachment 272290 [details] [diff] [review]
patch

This prints backgrounds if any author-level style sheets contain 'print' in their media list.
Comment 7 Kenneth Herron 2007-07-16 05:12:01 PDT
Comment on attachment 272290 [details] [diff] [review]
patch

I'm not really a reviewer, but fantasai asked me to look at this.

>--- widget/public/nsIPrintSettings.idl	30 Jun 2007 21:26:13 -0000	1.34
>+++ widget/public/nsIPrintSettings.idl	14 Jul 2007 06:01:48 -0000
>@@ -72,8 +72,8 @@
>   const unsigned long kInitSaveFooterLeft     = 0x00000010;
>   const unsigned long kInitSaveFooterCenter   = 0x00000020;
>   const unsigned long kInitSaveFooterRight    = 0x00000040;
>-  const unsigned long kInitSaveBGColors       = 0x00000080;
>-  const unsigned long kInitSaveBGImages       = 0x00000100;
>+
>+  const unsigned long kInitSaveBackgrounds    = 0x00000100;

It might be nice to replace the kInitSaveBGColors line with a comment that 0x80 is unused. See my patch on bug 315687. Also, you need to change the nsIPrintSettings uuid, and take note of bug 388169 if you try to check this in anytime soon.

>@@ -105,6 +105,11 @@
>   const long kPrintEvenPages    = 0x00000002;
>   const long kEnableSelectionRB = 0x00000004;
> 
>+  /* Print Backgrounds Enums */
>+  const short kPrintNoBackgrounds     = 0;
>+  const short kPrintAllBackgrounds    = 1;
>+  const short kPrintSomeBackgrounds   = 2;

I question whether it's necessary to change this to a tri-state value. We could just add some new logic to honor print stylesheets in spite of the existing pref, and control that logic with an additional pref (or not, and wait to see if anyone complains). That way, you wouldn't have to obsolete the existing pref or touch any of the code that supports them.

If you do stick with this, "SomeBackgrounds" isn't very descriptive. Maybe "StyledBackgrounds"? Some kind of comment in the IDL would be nice, at a minimum.

>@@ -206,8 +211,7 @@
>   attribute double  marginRight;
> 
>   attribute double  scaling;      /* values 0.0 - 1.0 */
>-  attribute boolean printBGColors; /* Print Background Colors */
>-  attribute boolean printBGImages; /* Print Background Images */
>+  attribute short   printBackgrounds; /* Print Backgrounds */

Similarly, I question the need to merge the colors & images flags. I realize they're merged in the UI, and refactoring is generally good. But it obsoletes everyone's current prefs, it doesn't reduce code complexity much, it removes flexibility from the platform, and it causes this patch to touch additional files that wouldn't be changed otherwise.

>--- layout/base/nsPresContext.h	4 Jul 2007 20:40:14 -0000	3.179
>+++ layout/base/nsPresContext.h	14 Jul 2007 06:01:38 -0000
>@@ -536,19 +536,32 @@
> [snip]
>+  enum backgroundPrint {
>+    ePrintNone     = 0,     // kPrintNoBackgrounds
>+    ePrintAll      = 1,     // kPrintAllbackgrounds
>+    ePrintFriendly = 2      // kPrintSomeBackgrounds
>+  };

I might be off base here, but does nsPresContext need to be concerned with the tri-state nature of this setting? I would think it's only concerned with the current print operation. At this point, all of the prefs and other logic just boil down to "are we printing background stuff", doesn't it?
Comment 8 fantasai 2007-07-16 09:53:09 PDT
> Similarly, I question the need to merge the colors & images flags.

As far as removing flexibility goes, I don't see this as a real problem because I can't think of any cases where you'd want to print background color but not images or vice versa. It also complicates the number of states we have once we add in the print-friendly-only option.

Obsoleting existing prefs is a valid problem. If the type system for prefs is capable of converting booleans to integers, then simply using printBGColors instead of printBackgrounds could solve that problem. Otherwise, the only way is to use two booleans (four states) to represent the three-state pref.

> I might be off base here, but does nsPresContext need to be concerned with
> the tri-state nature of this setting?

nsPresContext needs to know because it does the check to see whether the style set contains any print style sheets.
Comment 9 Matthew Paul Thomas 2007-07-16 22:09:03 PDT
Camino currently has separate "Print Background Colors" and "Print Background Images" checkboxes in its Print dialog. I don't know why the Camino developers chose to do that.
Comment 10 fantasai 2007-07-19 17:23:22 PDT
So.. nsIPrintSettings.idl is out of bit flags for kInitSaveFoo. All 32 are in use. So either printing when a 'print' style sheet is available needs to be mandatory, or we need to merge the images and colors background print options somehow.
Comment 11 Melinda Grant 2007-07-19 18:56:29 PDT
I think we need to keep users in control of turning off backgrounds if they really want to, even in the presence of a print style sheet. So if fantasai's either/or are the only options, HP would prefer merging images and colors.

(Or is using a long for bit flags an option?)
Comment 12 Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-07-19 20:18:35 PDT
(In reply to comment #9)
> Camino currently has separate "Print Background Colors" and "Print Background
> Images" checkboxes in its Print dialog. I don't know why the Camino developers
> chose to do that.

It's not just Camino that has those options, it's all Mac Mozilla apps (although it looks like we were the ones responsible for getting the PrintPDE plugin in the tree in bug 186401).

You'd have to ask Conrad why he chose two separate boxes, though my guess is parity with MacIE, which had separate boxes for them and which has always had the best printing experience on the Mac.

FWIW, the only reason I can think of for separate prefs is pages with dark background colors, annoying background images, and light text; you'd want to print the background color to make the light text visible but get rid of the bg image to keep the text legible.  I don't know how common such pages are any more, but I know they were everywhere at one point.
Comment 13 Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-07-19 21:28:39 PDT
Created attachment 273081 [details]
sample problem page

In case anyone can't remember this ugly part of the web, here's a sample of a page like I described in comment 12.
Comment 14 fantasai 2007-07-20 00:20:45 PDT
> is using a long for bit flags

We're already using a 32-bit integer...

I can represent each pref combination we want as a different integer in an integer pref. That would work around the 32 bit limitation. It would require obsoleting the exiting printBGColors and printBGImages booleans in favor of the new pref, however. I think bz mentioned that we have pref migration code somewhere, I'll have to find out where.

Once I code up this change, someone will have to help me test on Camino, as I don't have access to a Mac for development.
Comment 15 Kenneth Herron 2007-07-20 03:50:09 PDT
(In reply to comment #10)
> So.. nsIPrintSettings.idl is out of bit flags for kInitSaveFoo.

The patch for bug 315687 is going to free five of these bits.
Comment 16 Kenneth Herron 2007-07-20 06:02:00 PDT
Come to think of it, you don't really need a separate bit flag for each setting. These flags just control loading & saving these settings to prefs. It would be reasonable to control loading & saving all of the background prefs through a single flag.
Comment 17 fantasai 2007-07-20 17:35:17 PDT
Created attachment 273202 [details] [diff] [review]
patch v2

New patch. This one adds an independent boolean pref for turning on the behavior proposed here. The new behavior is the default, i.e. backgrounds will print by default on pages that have 'print' style sheets. The patch doesn't affect any UI. I'll have to set up a windows build environment and test some of the changes there, but I can't build on Mac or on QNX(?), both of which are specifically affected by the patch. I will follow up with UI changes to Toolkit in bug 388246.

kherron, do the changes look ok so far?
Comment 18 fantasai 2007-07-20 17:45:26 PDT
amardare, I'm making some changes here that affect embedding/browser/photon, let me know if they're ok?
Comment 19 fantasai 2007-07-21 11:17:27 PDT
Patch works on Windows. Still need testing on Mac, especially on Camino, and on QNX. If someone could test those for me, that would help a lot.. I don't have access to either.

Added test directory to URL field; tests 1 and 4 should be enough to tell whether the pref is working correctly.
  http://fantasai.inkedblade.net/style/tests/printbg-pref/bg-printing-001
  http://fantasai.inkedblade.net/style/tests/printbg-pref/bg-printing-004
Comment 20 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-07-21 12:22:40 PDT
(In reply to comment #19)
> and on QNX.

You don't need to get testing there in advance; it's not a tier 1 platform.  If you break it, the port owner can fix it.
Comment 21 Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-07-21 20:39:19 PDT
I can't build anymore so I can't help, but Josh or Colin should be able to look at the Mac stuff for you.
Comment 22 philippe (part-time) 2007-07-21 22:39:37 PDT
(In reply to comment #19)
> Patch works on Windows. Still need testing on Mac, especially on Camino, and on
> QNX. If someone could test those for me, that would help a lot.. I don't have
> access to either.

Camino builds fine with that patch (checkout finish: Sun Jul 22 13:08:59 JST 2007).

> Added test directory to URL field; tests 1 and 4 should be enough to tell
> whether the pref is working correctly.
>   http://fantasai.inkedblade.net/style/tests/printbg-pref/bg-printing-001
>   http://fantasai.inkedblade.net/style/tests/printbg-pref/bg-printing-004
>

Printing to PDF, with both Camino's checkboxes turned OFF in the print options:
bg-printing-001: black on white
bg-printing-004: black on green + background image

I tested with a few of my own stylesheets, and most printed correctly; one failed: including an @media print {} block inside a linked media="all" stylesheet.
http://dev.l-c-n.com/_temp/print007.html

Comment 23 fantasai 2007-07-21 22:53:12 PDT
Comment on attachment 273202 [details] [diff] [review]
patch v2

Thanks a lot, philippe! The @media test doesn't work because I'm only checking media types applied to an entire style sheet. I figured that would be a better indicator of print-friendly styling. (Also it's an easier check.)
Comment 24 philippe (part-time) 2007-07-22 18:49:00 PDT
(In reply to comment #23)
> (From update of attachment 273202 [details] [diff] [review])
> ... The @media test doesn't work because I'm only checking
> media types applied to an entire style sheet. I figured that would be a better
> indicator of print-friendly styling. (Also it's an easier check.)

Authors start to use these constructions more, esp on larger sites. Use case is a small subset of pages in need of extra styling, and they prefer not to bloat the main stylesheets. In order to minimise http requests, all styling (screen and print) is kept in the same stylesheet.
But it is a minor quibble, and could be something for a follow-up bug, once the dust has settled on this one. 

Comment 25 Kenneth Herron 2007-07-26 10:52:10 PDT
Comment on attachment 273202 [details] [diff] [review]
patch v2

>RCS file: /cvsroot/mozilla/layout/base/nsPresContext.cpp,v
>retrieving revision 3.324
>diff -u -r3.324 nsPresContext.cpp
>--- layout/base/nsPresContext.cpp	16 May 2007 21:10:31 -0000	3.324
>+++ layout/base/nsPresContext.cpp	21 Jul 2007 00:19:25 -0000
>@@ -1323,6 +1324,16 @@
>     mPrintSettings = aPrintSettings;
> }
> 
>+void
>+nsPresContext::UpdateBackgroundDraw(nsStyleSet* aStyleSet) {
>+  NS_PRECONDITION(aStyleSet, "null style sett");

Typo in this string. Looks great otherwise.
Comment 26 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-08-03 00:03:00 PDT
So, I'm afraid to say that I'm liking this less the more I think about it.  A heuristic like this works reasonably well for existing content.  However, we're more than a handler for existing content:  we're providing an API that authors write and test content against.  Heuristics tend to make really confusing APIs.  I can certainly see authors being confused and upset that a small change like adding a print style sheet to specify one thing would drastically change a printing experience that they've already tested.  If we want authors to care about writing content for us, we should care about them, and provide them with good APIs.  In this case, that probably means giving the author an explicit mechanism to say that the backgrounds were intended for printing.

I'm curious what other browsers do here?  Do they sometimes print backgrounds, always print backgrounds, or never print backgrounds?  If sometimes, is it a user option, or some other method?

Could such an explicit mechanism be standardized across browsers?


I also think this needs a bit more discussion of the user interface.  How much is the Page Setup dialog seen by users as something applying to "this page" and how much is it seen as something applying to "all pages"?  I think the UI design your proposing is one that makes sense for the latter situation, whereas I see this preference as something that makes more sense to use on a per-page basis.  If Page Setup is for permanent things, does it really even belong there?

There's been a lot of concern about improving our printing experience; I think it's probably worth snagging beltzner or somebody on his team for a discussion.
Comment 27 fantasai 2007-08-03 10:05:38 PDT
Adding a print style sheet isn't a small change, it's an explicit indication that the user is starting to think seriously about print, and I think allowing them to manipulate backgrounds is a reasonable reward for them making that step. Adding an extra switch unnecessarily complicates things. Note that we (and other UAs) already have a pref that turns on background printing for everyone. If their style sheet is written to assume they won't print, their design is already broken.

Other UAs, like us, have an on/off switch. HP is lobbying to get them to make the same change we're making here.

If you have concerns about UI, you can read/comment on bug 388246. Beltzner has already proposed UI there. mconnor was also present in the IRC discussion that led to that.

Yes, a per-page model would be nice, but that would be a much bigger change, codewise and UI-wise. Even in that case, I would want us to keep the auto behavior implemented here as the default. Most people just want to hit print and get readable output, and authors who care about print want them to get pretty output. This behavior can make both groups happy.
Comment 28 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-08-03 10:52:26 PDT
(In reply to comment #27)
> Adding a print style sheet isn't a small change, it's an explicit indication
> that the user is starting to think seriously about print, and I think allowing
> them to manipulate backgrounds is a reasonable reward for them making that
> step.

I don't think thinking of it as a "reward" makes sense.  As an API, it breaks invariants that authors can reasonably expect:
 * Linking to an empty style sheet shouldn't have any effect
 * media="print" and @media "print" should have the same effect
Specs describe what should happen when an author links to a style sheet.  This isn't part of what they describe, and the behavior will confuse authors.
Comment 29 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-08-03 10:54:22 PDT
I think it's worth bringing this up on www-style and perhaps some more author-oriented mailing lists to see what people think the mechanism should be.
Comment 30 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-08-03 11:24:36 PDT
Also, I'm honestly not sure in what cases having "Print Backgrounds" turned off helps things.  In cases where there are dark backgrounds, it will lead to unreadable text, since the light text won't show up on the light background.  In cases where there are light backgrounds, why would turning it off be desirable in the first place?

Should we consider just changing the default to on?
Comment 31 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-08-03 11:25:44 PDT
That said, if the switch ignored both colors and backgrounds, I could see it being more useful in correcting pages with dark backgrounds.  Maybe we should be doing that instead?
Comment 32 Kenneth Herron 2007-08-03 11:51:00 PDT
Netscape 4 had options to force text and lines to black. See bug 153363 and the page setup image attached to it.
Comment 33 fantasai 2007-08-03 15:20:09 PDT
> I don't think thinking of it as a "reward" makes sense.

I think of it more like "if you've taken the trouble to provide a dedicated style sheet for print, then I will trust that you are not going to abuse the printer and therefore I will allow you use of its ink for your backgrounds".

> it breaks invariants that authors can reasonably expect:

I don't think authors really care about that first invariant and would gladly give it up to be guaranteed printable backgrounds.
For the second, I'm willing to entertain the argument that I should be checking for @media statements as well. I don't consider them as reliable an indicator of whether the author has designed his site for print, because as philippe points out, they are often used in local style sheets. Their presence therefore doesn't represent whether the global style sheet was as considerate of printers as the local style sheet author. However if you feel it is necessary to make this change acceptable, I will implement that.

> why would turning it off be desirable in the first place?

Saves ink. Ideally for print, you want a design based on black text on a white background, but you also want to use some backgrounds for accenting. If painting backgrounds is off, you get close to that for most pages, because most pages use dark text on a light background. For pages where there is hue contrast but little luminosity contrast, you also get more readable output on b&w printers because the background color at least has been shifted to white. For pages that are white text on a dark background, you get junk printouts and if they're important to you, you'll have to print again with backgrounds turned on. But in all cases, you haven't unnecessarily poured expensive ink all over your printouts.

I think backgrounds off is a pretty reasonable default. It's not ideal, but it deals well with most pages out there. But for the authors who want to put in the time and effort to provide the ideal, I think we should provide them the opportunity.
Comment 34 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-08-03 15:48:52 PDT
It's not that authors care about the invariants because they think about invariants.  It's that when the invariants are broken, authors won't understand what happened and are likely to be confused.
Comment 35 fantasai 2007-08-04 15:51:16 PDT
BTW, we already have code to darken light colors when background printing is off. See http://lxr.mozilla.org/seamonkey/search?string=DarkenColor and bug 141232.
Comment 36 fantasai 2007-08-22 23:42:02 PDT
I posted in css-discuss about this and didn't get much of a response. I did learn, however, that some authors assume backgrounds never print, period. The one person who replied said he puts rules to darken text color in the print style sheet, but doesn't modify the background at all. Authors are confused anyway, I don't think breaking your stated invariants is going to make things any worse, and it'll at least steer authors clear of more harmful assumptions about invariants that don't exist. Nobody is going to add an empty print style sheet on a production site. In development the author might be surprised when backgrounds suddenly print but at least he isn't assuming they never print. The surprise is not harmful. Assuming backgrounds never print is harmful: the site can become unreadable when background printing is on. Hacking borders to mimic backgrounds is harmful: the user cannot turn them off. Accepting this patch trades in harmful assumptions for harmless surprise, please let's make this change.
Comment 37 fantasai 2007-08-22 23:48:11 PDT
"at least >in production< he isn't assuming they never print"
Comment 38 fantasai 2007-10-01 21:46:50 PDT
dbaron, can I get some useful comments on what to do next here? You don't like my patch, but you haven't suggested any alternatives: I'm kinda stuck here.
Comment 39 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-10-05 10:59:55 PDT
I suggested an explicit mechanism for authors in comment 26.  (For example, something like a meta element or an @-rule -- maybe even more than one option.)
Comment 40 Hixie (not reading bugmail) 2007-10-05 14:58:57 PDT
I'm on the side of just having the pref be defaulted to "print backgrounds", and having the other state be "reduce ink use when printing" (and having that drop dark backgrounds and darken light text). Also I think this pref should be in the print settings dialog, not in prefs, since it's more likely to be a per-page decision than a per-user decision.
Comment 41 Joel Rees 2008-04-27 21:56:57 PDT
I am using the background image to add rules to a simple web app for generating vocabulary practice worksheets. I'll put up a sample at 

http://reiisi.homedns.org/~joel/cs/ranbunhyou/scramble.html

within a few hours.

I don't know what MSIE currently does. Safari has the flag to enable printing background images buried in the Safari options of the print dialog, which pretty nearly makes my webapp useless to about half of one of my target audiences. I'll raise cain over there later on.

I don't know about Camillo, but Firefox on Mac currently has no way to get to the preference except via the about:config uri. No comment on that necessary, right?

I don't care what authors confused by bad support of CSS in past browsers may think they want, if there is a CSS style that specifies print media _and_ that style specifies background images, a browser that doesn't print the specified background by default is broken.

(On the other hand, if the non-print media style specifies backround and the print style does not, I'd have to read the spec on which gets precedence before I could say which is correct. And I'd hate to suggest making the browser try to guess how much ink is going to be used and warn the user on high-ink-volume pages, but if web authors abuse the spec, it would be a better use of spare cycles than many other things.)
Comment 42 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-04-27 22:49:27 PDT
(In reply to comment #41)

> I don't know about Camillo, but Firefox on Mac currently has no way to get to
> the preference except via the about:config uri. No comment on that necessary,
> right?

You've undoubtedly hit the old bug where viewing a page with a plugin has disabled the "appname" pane of the print dialogue; Camino and Firefox both use the same PrintPDE, and the checkbox to enable/disable printing of background images is present in both.
Comment 43 Robert A. Kelly III 2009-06-09 21:20:14 PDT
I think that all print media-specific css rules should be honored by default. As of Firefox 3.5 beta 4, I still have to explicitly enable background printing, there is nothing the author can do to indicate a background is suitable and intended for printing. While some authors may assume that no backgrounds are ever printed, they wouldn't be making a print media specific declaration if they didn't intend the background to be printed.

I think the best option is to have the browser default to current behavior for all backgrounds, except those which are specified for print. This gives the thoughtful designer the opportunity to include appropriate styles specifically for printing. There would still be the options to print all backgrounds, or to print no backgrounds. The sort of UI described in comment #3 sounds good to me.

To be clear, I don't think the mere presence of print media specific styles should alter the interpretation of any /other/ style, only that the print-specific styles themselves should be honored by default.

I am a web designer and power user, so that is my background and perspective on the subject.
Comment 44 Logan Rosen [:Logan] 2011-12-20 06:24:07 PST
*** Bug 322008 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.