W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

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

From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
Date: Tue, 18 Aug 2020 12:25:41 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-675447163-1597753540-sysbot+gh@w3.org>
> So I agree it's "the page box minus margins". We don't accept viewport units in @page dimensions at all, they collapse to auto the same way a percentage against shrink-to-fit does. So size: 100vw 100vh is invalid. I don't know about the other print engines.

Interesting, so they just compute to auto? Get parsed as auto? They don't get parsed? Something else? If we decide making this dependent on @page rules, it should be defined! :)

> > Media queries do not honor size: they assume the paper size that would be chosen if no @page rules were specified
> I think that's a very problematic sentence. Without a @page rule the default page size is auto - UA dependent, so effectively undefined. Which means any width/height related media query is also UA dependent in print. I'm pretty sure we can, and should, improve on this.

I don't get why that would be problematic? The user should be able to choose a page size, and this allows the website to react to that.

> I don't think evaluating MQ width/height against the the "first page" is useful, as that's layout dependent - for example, the first page here is arguably[1] landscape, not portrait...

That's fair. I agree, and I think we should evaluate with the default page size, but it seems you disagree with that per the above :)

> But you could define the media width/height against the size of the last unqualified page rule - i.e. the highest priority @page rule that has no selectors and is not itself nested inside a @media or imported from a media-qualified @import. This is unambiguous once you've parsed all the stylesheets, and doesn't require layout to evaluate

This is indeed a workable and possibly nicer solution, specially if you fallback to the default page size if there's no `@page` rule specified size / margins. I'm a bit concerned about the complexity though: it requires two passes instead of one over all rules in the page, and it makes stuff like `matchMedia` depend on the stylesheets currently applying to the page which is a bit annoying :)

> Finally, I'm not sure I agree that media-query "width" should be defined to equal 100vw. Media has a very specific meaning in print (eg "Media Box" in PDF means the size of the physical page, which is well-known terminology). Personally, I don't find the fact it's not 100vw problematic - media != viewport. [EDIT: and in fact RealObjects and AH both have non-standard units that evaluate against physical media size, not viewport size]

I would expect `device-width` to be the full page size, and `width` to match viewport units, fwiw. Seems more similar and author-friendly to screen-based pages where `width` matches viewport units while `device-width` may be larger.

When printing pages that were not designed for print, it's not hard to imagine something like:

@media (min-width: 900px) {
  #container { width: 900px; }

Or such. If viewport units don't match the `width` media feature, then this would cause stuff to overflow outside of the content box, which means lost content and sad user :)

GitHub Notification of comment by emilio
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5437#issuecomment-675447163 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 August 2020 12:25:43 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC