- 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
> 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: ```css @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