[csswg-drafts] [css-mediaqueries] [css-page] Viewport units / media queries interaction in print documents. (#5437)

emilio has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-mediaqueries] [css-page] Viewport units / media queries interaction in print documents. ==
Per spec, while printing, currently:

 * The width / height media features are compared against the "page box", which is the box without subtracting margins, per https://drafts.csswg.org/mediaqueries-5/#width / https://drafts.csswg.org/css2/#page-box.

 * In https://drafts.csswg.org/css-values-4/#viewport-relative-lengths it is deferred to css-page, but there's no mention of `vh` or `vw` or viewport relative units in that spec. So following the usual definition, viewport units resolve against the width of the ICB, which is the page box minus margins.

This is, as an author, I think, a bit unfortunate. I think these two should match (and IMO it should be the later).

Regardless of whether we decide to keep stuff as-currently-defined, there are other issues... Should we account for `@page` rules, as these can change both sizes and margins? If so, which page size should be considered? The first one? The largest? (the largest is not really possible to compute I think, as that'd be circular).

Some of this circularity is intended to be addressed in the size property definition https://drafts.csswg.org/css-page-3/#page-size-prop:

> If a size property declaration is qualified by a width, height, device-width, device-height, aspect-ratio, device-aspect-ratio or orientation media query [MEDIAQ] (or other conditional on the size of the paper), then the declaration must be ignored. Media queries do not honor size: they assume the paper size that would be chosen if no @page rules were specified.

But that's not great in two different ways:

 * First of all, it doesn't solve the circularity, as `@page { size: 101vw 101vh }` would still be circular with the current definition.
 * Second, it is not how we've dealt with this kind of things in the past (like `rem` units, where we've generally just provided a sensible initial value). This definition causes the process of collecting rules for a given paged document to have two passes, which is not amazing.

Current status in browsers is the following:

 * Firefox: Does something useless for viewport units. Uses the page box size for `@media`, without accounting for `@page` (we don't support `@page { size }` yet anyways). Note that I'm likely changing this in https://bugzilla.mozilla.org/show_bug.cgi?id=1414600 to always use page-box-minus-margins without accounting for `@page` margins for both viewport units and `@page`.

 * Chrome: Does page-box-minus-margins accounting for `@page` rules for viewport units. I haven't figured out what they exactly do for media queries, but it doesn't make sense to me, see https://bugs.chromium.org/p/chromium/issues/detail?id=1117050

 * WebKit: Does page-box-minus-margins for viewport units as well. Doesn't seem to support `@page { margin }` or `@page { size }`.

Status from print engines would be very useful here I think.

I think the sanest way to prevent circularities is to not account for `@page` neither for viewport units nor media queries (if the author is specifying the margin, they can deal with it just fine). But I think this should be better defined over-all. Though maybe I've missed some place?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5437 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 17 August 2020 16:00:19 UTC