Re: [mediaqueries] Printing media queries - media color and ink saving

> On 07 Mar 2015, at 18:34, Henrik Andersson <henke@henke37.cjb.net> wrote:
> 
> I have been thinking about printing. I am no expert, I don't even have a
> printer of my own, but there are some features that I think would make
> sense as media queries.
> 
> The first one is being able to detect the color of the medium, the paper
> color that is. Authors might want to adjust colors to suit the paper
> color, especially with regards to printer limitations. To do this one
> would need a query of some sort to check what the medium color is. This
> is a troublesome value to check, it's a color. As far as I know, there
> are no media queries using color values. Which leaves the problem of
> figuring out how to do the matching.

Hm, this seems tricky. I agree with you that if the media being rendered on isn't white,
it would be useful for authors to know about it and be able to react. However, it isn't
exactly clear how a media query would work. Testing for specific colors is
certainly not the right approach.

When "not white" means dark, we might be able to handle this using same queries that deal with contrast, color inversion, light-on-dark screens, etc. These are not in the spec yet, but is something the WG has agreed need to be added. We need to figure out exactly how, but it's coming.

But for dealing with color tints, I am a lot less sure that a media query is the right tool. It feels like exposing the media color through or variable or something so you can do color math on it is probably closer to what you'd need.

But if you have an idea on how to design a useable media query for this, please do share.

> The second feature is the one that inspired me to start this discussion.
> Ink saving. My browser, SeaMonkey, allows disabling backgrounds when
> printing. Obviously I as an author need to know about such a major
> change to make the layout work correctly. The @supports system seems
> like a good solution for this specific problem. But this makes me think,
> is this not just a special case of a more generic idea? User agents may
> want to perform various operations in order to save on ink. Is this
> something worth being able to adjust the layout for?

Right, this has been discussed a few times, and there is general (although it is not unanimous) agreement that this would be useful.

In addition to the one you're talking about, there are a few other media queries that end up being similar: high contrast, bright-text-on-dark-background... All these are similar in that the MQ may need to indicate a combination of two things:
- it is desirable to tweak the styling for a particular goal (ink saving, contrast adjustment...)
- the UA has made some automatic adjustments to your styles in order to achieve that goal.

For all situations like this, we've found so far that the best design would be to have a media feature and a property.

The media media feature would have 3 values:
- everything is normal

- ink saving (for instance) is desirable, and it is up to the author to make it happen; the UA has not taken any particular steps towards this goal.

- ink saving (for instance) is desirable, and the UA has automatically adjusted some properties

The property would let you disable these automatic adjustments, so that you can provide an alternative way to reach the same goal that is more suitable to your content.

This is more robust that an media query letting you know that background have been disabled, because disabling backgrounds is not the only adjustment browsers do to save ink, and having lots and lots of media queries to test of all the things that can potentially be disabled or tweaked is not going to be a scalable or robust solution.

With the design as proposed above, you can either let the UA do it's magic, or provide an alternative way of saving ink which is better suited to your content.

Of course, it also allows authors to insist on wasting ink, but:
- you would have to do that on purpose, and we can't really prevent authors from making lousy designs if they want to
- this can be countered by putting !important in the user style sheet on the property to keep the UA ink-saving adjustments on.

The reason why this is not yet in the spec is that there seems to be quite a few scenarios besides ink-saving where this combination of a MQ and property are needed (many related to accessibility). We wanted to investigate the whole set to make sure the design worked well before writing it down, but haven't yet been able to find the time to do so.

 - Florian

Received on Monday, 9 March 2015 09:25:38 UTC