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

Thanks @emilio for bringing this one up. Yes, viewport units are a bit of a pain point for us, when applied to font sizing anyway.

* PDFReactor [defines](https://www.pdfreactor.com/product/doc_html/index.html#SupportedLengthUnits) `vw` as _"Equal to 1% of the width of the content area of the first page"_
* Prince doesn't claim support for `vw` in their current documentation, but they are ["on the roadmap"](https://www.princexml.com/forum/topic/2728/css3-units)
* Antenna House Formatter [defines](https://www.antenna.co.jp/AHF/help/v70e/ahf-ext.html#ext-unit-conf) `vw` as _"Unit of the width expressing the viewport width as 100. It cannot be used with elements for which a viewport, such as the root element, has not been established"_. But I'm struggling to parse that.
* We treat `vw` as 100% of the content-box of the current page, so you can fragment a table that is `width: 50vw` from portrait to landscape and it will increase in width. This is what I believe is currently specified. But, we still have issues breaking text where font size is in viewport units, eg `font-size: 80vh` and the page size changes.

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.


Media Queries are more interesting. RealObjects, Prince and ourselves allow the nominal page width/height to be set externally - I've no information on AH formatter. And I hadn't spotted this sentence until you pointed it out:

> 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 - currently - effectively undefined in print. I'm pretty sure we can, and should, improve on this.

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:
```css
@page cover {
    size: a4 landscape;
}

<html>
 <body>
  <img style="page: cover"/>
```

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. And it still lets you do stuff like this, which might be tricky otherwise:
```css
@media print and (width: 210mm) and (height: 297mm) {
    @page landscape {
        size: 297mm 210mm;
    }
}
@media print and (width: 8.5in) and (height: 11in) {
    @page landscape {
        size: 11in 8.5in;
    }
}
```
I could imagine this rule in an author stylesheet, and a @page rule selecting the current paper loaded into the printer being set in the user stylesheet generated by the print dialog (for example). Without any @page rule the rule collapses to what we have now, so there's no compat issue for Prince, RealObjects and ourselves .

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.

[1] Not just arguably but actually in Prince and our product; untested elsewhere.


-- 
GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5437#issuecomment-675363039 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 09:14:47 UTC