[MFD] W3C CSS Mailing List Printing Discussion - Browser Job Ticket?

[MFD] W3C CSS Mailing List Printing Discussion - Browser Job Ticket?

Paul Tykodi ptykodi at tykodi.com
Thu Aug 11 19:21:50 UTC 2011


Hi,

There has been a discussion going on within the W3C CSS working group about
the best way to specify printing backgrounds when executing a print job from
a web browser since Feb 2011. My question is whether a portion of the PWG
Semantic Model might form the basis for a Web Browser Job Ticket format that
could be incorporated into CSS to help with printing issues like this one.

I am curious to know whether the PWG believes we have any information in our
semantic model that might help the W3C CSS working group with user intent
when executing a print function?

The original description of the specific issue being discussed is included
below:

<Begin copied e-mail>

"From: www-style-request at w3.org [mailto:www-style-request at w3.org] On Behalf
Of Ian Fette (????????)
Sent: Tuesday, February 22, 2011 12:17 PM
To: www-style at w3.org
Subject: Printing and background colors/images

Summary: Want authors to be able to specify whether backgrounds should be
printed.

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.

Thoughts?"

<End copied e-mail>


 Best Regards,

/Paul
--
Paul Tykodi
Principal Consultant 

Tykodi Consulting Services LLC
3 Lowell Ave.
Dover, NH 03820-2705
Secretary - IEEE-ISTO Printer Working Group 
Co-Chair - IEEE-ISTO PWG IPP Working Group

e-mail:   ptykodi at tykodi.com 
tel:          (603) 343-1820 
mobile: (603) 866-0712 





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the mfd mailing list