10BC0 [css-mediaqueries] [css-page] Viewport units / media queries interaction in print documents. · Issue #5437 · w3c/csswg-drafts · GitHub
[go: up one dir, main page]

Skip to content

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

@emilio

Description

@emilio

Per spec, while printing, currently:

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?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0