Re: background-print

I've also had real world cases where I _needed_ the backgrounds to print because the page design relied on backgrounds to convey information and the page wasn't designed for print at all. I wound up wasting time, ink, and paper printing the page twice after digging through browser settings trying to find the control to turn the backgrounds back on… now, how many users are out there that don't even know there's a switch for that?

User choice is important, but only if the choice is actually presented to the user in a meaningful and relevant manner so that they can actually make an informed decision.

What I really want is a good print dialog, one that shows me all my choices (print stylesheet(s), screen stylesheet(s), alternate stylesheet(s), backgrounds on/off, color/monochrome, etc) with live previews and lets me pick which way to print the document… (and sure, if you want to add UI to suppress printing ads or select regions of the page to print I'm happy with that as well)

Peter

On Aug 14, 2011, at 1:04 PM, Tantek Çelik wrote:

> Agreed with Brian.
> 
> Real world use-case / scenario to illustrate both examples Brian gives:
> 
> * Print a Southwest Airlines boarding pass.
> 
> The publisher (author) creates a special "print version" that has tons
> of colors and ads for things.
> 
> I (user) have *no desire* to waste ink/$ on printing ads or color for
> all that I need: a black&white bar/QR code.
> 
> It's my $ for ink, my printer, I should have the final say to be able to:
> * not print the ads (click to display:none them, there might be an
> add-on to do this)
> * print in black&white (seemingly harder, unless someone has a
> user-stylesheet suggestion).
> 
> As a workaround I've: printed to PDF, zoomed on just the boarding pass
> with QR code, taken a screenshot, printed that. Works but annoying.
> 
> So yes, this conflict exists today, and we should design to empower
> the user, and the browser, as the user's agent, to follow the user's
> preferences over the author.
> 
> Tantek
> 
> On Sun, Aug 14, 2011 at 12:51, Brian Manthos <brianman@microsoft.com> wrote:
>> Even if a page author has "designed the page with printing in mind", the user might still disagree and want to opt out of printing the images anyway.
>> 
>> From an paid-for application perspective, user choice is king.
>> From a content-author perspective, author choice is king.
>> 
>> This isn't a new conflict, and I'm sure it will be going for a while.
>> 
>> Another example: ad blockers.
>> 
>> -Brian
>> 
>>> -----Original Message-----
>>> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
>>> Sent: Sunday, August 14, 2011 10:22 AM
>>> To: Sylvain Galineau
>>> Cc: Brian Manthos; fantasai; www-style@w3.org
>>> Subject: Re: background-print
>>> 
>>> On Sat, Aug 13, 2011 at 11:31 PM, Sylvain Galineau
>>> <sylvaing@microsoft.com> wrote:
>>>> [Tab Atkins Jr.:]
>>>>> A property with a properly-broad name, like "printer-safe-colors",
>>> would
>>>>> allow the author to hint in that direction.
>>>>> 
>>>> 
>>>> Note that printing may not be the only motive for background
>>> suppression
>>>> and higher contrast. Accessibility settings on some platforms also do
>>> this
>>>> to view the content. High contrast is not just a printing issue.
>>> 
>>> Keep in mind the intent of the property, though - it's meant to say
>>> "Hey, I know you normally suppress my backgrounds and mess with my
>>> colors when you print, but I've designed the page with printing in
>>> mind, so there's no need to do that here (unless the user still asks
>>> for it)."
>>> 
>>> While I agree that there are other use-cases for UAs messing with
>>> colors, I don't think it's good to mix the "I've thought about
>>> printing" declaration with an "I've thought about contrast levels"
>>> declaration.
>>> 
>>> ~TJ
>> 
>> 
> 
> 
> 
> -- 
> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
>

Received on Monday, 15 August 2011 00:54:19 UTC