Re: Printing and background colors/images

On 23 Feb 2011, at 01:11, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Tue, Feb 22, 2011 at 4:55 PM, Jon Rimmer <jon.rimmer@gmail.com> wrote:
>> So, right now, browsers are not conforming to CSS 2.1 by ignoring
>> background properties when printing. Requiring backgrounds to be
>> duplicated in a print stylesheet, or adding a new property that
>> applies only to print media would essentially standardise this
>> non-conformity as part of CSS 3. This seems wrong.
> 
> Why does it seem wrong?  Browsers have agreed pretty uniformly that
> printing backgrounds is bad, despite the fact that it's technically
> required.  The correct course of action is thus to specify that
> behavior, rather than leaving the spec in conflict with reality.

So long as the proposal is to add the new property to 2.1, then it will. I was concerned the idea was to have this property in some new CSS 3 spec, in which case 2.1 would still be wrong.

> 
>> My suggestion of a default user-agent print stylesheet that turns off
>> backgrounds would at least resolve this non-conformity. However, a
>> more 'proper' solution would seem to be reorganising the CSS 2.1 media
>> types to reflect the reality of browser behaviour. This could be done
>> by creating a new media group called, perhaps, 'visual-decorative',
>> into which the background properties would be moved. The 'screen'
>> media type would map to this group, but print would not. You could
>> then create an additional media type called 'print-rich', which
>> _would_ map to 'visual-decorative'.
>> 
>> Browser behaviour could then be to default to 'print' media type for
>> printing, unless a stylesheet has been linked that is mapped to the
>> 'print-rich' media type like so:
>> 
>> <link rel="stylesheet" href="foo.css" media="screen, print-rich" />
>> 
>> This would also allow users to specify both print and print-rich
>> stylesheets, and also mean that browsers current ability to turn
>> on-and-off background printing would be relatable to CSS, as it could
>> represent the choice between defaulting to printing using the 'print'
>> media type vs the 'print-rich' type.
>> 
>> Obviously, it's not ideal to be making changes like this to CSS 2.1 at
>> this point, but if the alternative is that it will be perpetually
>> wrong, it seems preferable.
> 
> I'm not sure I like this.  It requires magic behavior switching based
> on the presence or absence of a stylesheet matching a particular media
> declaration.  This seems similar to Opera's full-screen-mode switching
> based on whether or not there's a media=projection stylesheet
> somewhere in the document (if there is, match 'projection' but not
> 'screen', if not, match 'screen'), which I believe is a fairly clumsy
> design decision.

The exact mechanism to apply the different media type isn't really the point, and it could easily be made more explicit by adding a new media rule or some other syntax.

The important point is that the problem as it stands is with how CSS 2.1 maps properties to media types, and the fix should address the root cause using the mechanisms the CSS standard already provides to do this. It should not introduce a special case where the normal rules by which properties apply to media types are thrown out the window. That seems far more 'magic' and opaque than any form media type selection.

A key principal of software engineering is that you should always try to fix errors in the component or layer where they occur, rather than trying to work around them at a higher level. I think the same principal applies here: the problem is that the spec says backgrounds apply to print media, and it should be resolved by reorganising the media types, or by introducing some general method to make them more flexible, not by adding an ad-hoc, media type specific property or behaviour.

> ~TJ

Jon