(In reply to Emilio Cobos Álvarez (:emilio) from comment #4) > I'm not convinced we should account for `@page`, see https://github.com/w3c/csswg-drafts/issues/5437 It feels pretty broken in the print-to-PDF case, where we're apparently resolving these against some default paper size that we're not actually using for the print-to-PDF output at all. For pages that we print to different-sized paper, it's maybe more debatable, though I feel like the Chrome behavior is more intuitive...
Bug 1835108 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #4) > I'm not convinced we should account for `@page`, see https://github.com/w3c/csswg-drafts/issues/5437 It feels pretty broken in the print-to-PDF case (comment 1), where we're apparently resolving these against some default paper size that we're not actually using for the print-to-PDF output at all. For @pages that we print to different-sized sheets(comment 2), it's maybe more debatable, though I feel like the Chrome behavior is more intuitive...
(In reply to Emilio Cobos Álvarez (:emilio) from comment #4) > I'm not convinced we should account for `@page`, see https://github.com/w3c/csswg-drafts/issues/5437 It feels pretty broken in the print-to-PDF case (comment 1), where we're apparently resolving these against some default paper size that we're not actually using for the print-to-PDF output at all. For @pages that we print to different-sized sheets(comment 2), it's maybe more debatable, though I feel like the Chrome behavior is more intuitive... (where `100vh` resolves to the same value as `height:100%` on the root element, in all the cases I've tested)