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

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.

> Webkit is interested in finding some way for authors to provide a hint to the browser that they've thought about printing,

That part is covered by encountering more specific media queries than ‘all’ which include ‘print’, i.e. option (2) below.

> and the backgrounds they've set are significant and should be printed.

That’s not guaranteed with the above. Of course, styles – including background colors and pictures – should never be semantically relevant, but images inserted with the ‘content’ property may carry the same meaning as the text in the markup they replace and it’s hard to guess whether they’re only screen-appropriate or also sensible for printing.

> (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.

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.

> (3) Honor !important backgrounds
> 
> People use !important for a lot of reasons, …

Yes, I consider this hackier than (2). Håkon is right, though, that we could introduce further exclamation-mark keywords to either suggest or prohibit certain values in certain media. That would be similar to proposals of ‘!required’ and the like.

> (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.

> (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).

This option would make more sense if we had low-level stuff like

  @page {
    print-media-type: glossy paper;
    ink-type: CMYK;
  }

> (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.

> Thoughts?

Preferably better print dialogs, but otherwise (2) or (4b) from the options you presented.

Received on Tuesday, 16 August 2011 13:24:44 UTC