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

Re: [css3-gcpm] Printing backgrounds (thread reboot)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 16 Aug 2011 14:33:10 -0700
Message-ID: <CAAWBYDBgkmGej0K8qaZoRmGHuvG_-=FjiWSm=WjXzkjoCBkj6w@mail.gmail.com>
To: Christoph Päper <christoph.paeper@crissov.de>
Cc: www-style list <www-style@w3.org>
On Tue, Aug 16, 2011 at 6:24 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>> 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.
>
> All those UIs are broken and should be fixed.

Balancing options with simplicity is always difficult.  Most of the
time this option is unimportant.  Patches welcome if you can justify
the change to our UI leads.


>> (1) Honor any style present in a print stylesheet.
>> (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.
>
> I don’t see the problem, if we pretend that browser default stylesheets had something like
>
>  @media all   {:root {color-and-background-handling: normal/*=default*/;}}
>  @media print {:root {color-and-background-handling: auto/*=magic*/;}}
>
> or the same with ‘@page’ instead of ‘:root’. It’s in no way hackish.

I don't understand.  If we introduce a new property, that's solution 4, not 2.


> Anyhow, we could also introduce another media feature to Media Queries, like ‘color-cost’ or ‘color-preference’, or reuse existing ‘color’/‘monochrome’, ‘resolution’, ‘grid’ with special meaning applied.

Sure, but that would still require a new property to actually work.


>> (4) Create a new property controlling this
>>
>> printer-friendly-colors: _auto_ | avoid
>> printer-color-adjust: _auto_ | avoid
>> printer-colors: _auto_ | exact
>
> Why should this be printer-only? I could easily envision it useful for screen media, too, e.g.:
>
>  color-adjust: red-green-impaired;
>  color-adjust: high-contrast;
>  color-adjust: negative;
>  color-adjust: grayscale;
>  color-adjust: black-and-white;
>  color-adjust: glossy-screen-in-the-sun;
>  color-adjust: dark-room;
>  color-adjust: depressed-mood;
>
> Those don’t say much about the preference for background images or other style-induced images or images at all, though.

Sure, these are all possible.


>> (4a) Limit it to applying to the root element only.
>> (4b) Expose this as a descriptor on the @page rule,
>
> This is almost the same as
>
>  @media (paged) {…}
>
> which we don’t have (yet).

Yeah.


> This option would make more sense if we had low-level stuff like
>
>  @page {
>    print-media-type: glossy paper;
>    ink-type: CMYK;
>  }

I don't know if it makes sense to directly control printers from CSS.
(In any case, that's out-of-scope for this feature, obviously.)


>> (4c) … specify a rendering intent in terms of color profiles
>>
>> 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.
>
> That *are* the semantics “print-friendly” UI options try to express. Hiding the background images and colors only is just the easiest thing to do. So if we did this on this level we would certainly need means to control any of
>
> * color in general
> * background color
> * background image
> * background color with text above it
> * background image with text above it
> * text color
> * content image
> * border color
> * border style
> * border image
> * …
>
>  guise-background: <guise> [<guise>]?
>  guise-content:    <guise> [<guise>]?
>  guise-border:     <guise> [<guise>]?
>
> The first value is for images (or both), the second for colors.
>
>  guise: <keyword>
>       | <guise> [<guise>]? [, <guise> [<guise>]? [, <guise> [<guise>]? ]? ]?
>
>  <guise>: _‘auto’_ /*= media-dependent*/
>         | ‘original’ | ‘none’
>         | ‘palette’ | ‘grayscale’ | ‘black-white’
>         | ‘vector’ | ‘bitmap’ | …
>  <keyword>:  /* see above for use case ideas */
>
> The ‘guise’ shorthand property – that’s perhaps not a good name, but ‘visibility’, ‘appearance’, ‘display’ are all take already – either accepts a keyword that sets the six possible values appropriately for a certain use case, or it accepts either one, two or three image/color guise combinations, where the first is for background, the second for content (text and pictures) and the last for borders (and the like). The background combination is used for the other ones when they’re not specified.

I don't believe we actually need that much control over this kind of feature.

~TJ
Received on Tuesday, 16 August 2011 21:34:06 GMT

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