Named pages aren't supported in any browser yet. For page-orientation, a non-supporting browser will just fall back to not rotating any pages, which will obviously give all pages the same orientation. This will not affect layout or the printed result on its own (only print preview and PDFs generated). However, browsers not supporting named pages will not insert the expected page breaks, and this may result in a different layout from a browser that does support it, obviously.
Some rendering engines (such as Blink) already support page-specific margins, but don't actually let that affect the available size on each page (there'll be one uniform page content size throughout the document). This is already observable when setting a different margin in a "@page :first" selector. With this change it will also be observable at any named page that specifies a margin. This will be fixed when Blink ships with LayoutNG block fragmentation - crbug.com/829028Firefox: Public support (https://github.com/mozilla/standards-positions/issues/346)
Edge: No public signals
Safari: No public signals (https://lists.webkit.org/pipermail/webkit-dev/2020-May/031216.html)
Web developers: Positive
Wanted by Google Docs
To actually rotate the layout as well, so that text and other content on rotated pages match with the page orientation, CSS transforms may be used. Another option, as briefly mentioned earlier, would be to let each page be represented by a CANVAS element.
Except for simple cases, using page-orientation generally requires the author to have significant control over layout of the document. This is however typically the case for a web-based word-processor, for instance.
Though maybe Chromium doesn't support this yet, adding Stephen on CC as
he has been following the changes on WPT regarding this.
It would be really nice to have WPT for printing features too.
Bye,
Rego
Mike West
unread,
Jun 18, 2020, 3:29:34 PM6/18/20
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to blink-dev, Manuel Rego, Stephen McGruer, Morten Stenshorne
LGTM1.
I'd note, though, that the TAG review was filed a bit late; it's not a good look for us to send a request for someone to take a look and then not really give them a chance to respond. I note that the Intent to Prototype left the "TAG Review" section blank. That's unfortunate.
That said, it's been a ~month, and Mozilla folks seem on board with the design. I've read through the mechanism and it seems reasonable, and supported by the CSSWG. For a feature like this, that's likely good enough.
Manuel Rego Casasnovas
unread,
Jun 18, 2020, 3:32:45 PM6/18/20
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Mike West, blink-dev, Stephen McGruer, Morten Stenshorne
LGTM2.
Still looking for a reply regarding possibilities for test printing in
WPT inside Chromium.
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Yoav Weiss, ecosystem-infra, Luiz Pereira, blink-dev, Manuel Rego, mste...@chromium.org, mk...@chromium.org
> Though maybe Chromium doesn't support this yet, adding Stephen on CC as he has been following the changes on WPT regarding this.
Apologies, I had missed this in my inbox (and thanks to Rego for raising it). Upstream WPT has nascent support for print-reftests now, but we do not yet have any support in downstream Chromium. I imagine we could maybe hook something up using internals, but would need to dig in to see how feasible this would be.
(Long term, we are moving towards a model where we use the upstream runner for WPT tests in Chromium, so that we don't have to do more work every time a new feature is added, but that's a few quarters out still.)
--
smcgruer • he / him
Stephen Mcgruer
unread,
Jun 21, 2020, 4:56:59 PM6/21/20
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Yoav Weiss, ecosystem-infra, Luiz Pereira, blink-dev, Manuel Rego, mste...@chromium.org, mk...@chromium.org
> would need to dig in to see how feasible this would be.
Initial investigations make it look fairly difficult, I'm sorry to say - internals.setPrinting() is very different from the way upstream WPT defined printing support. I've got an open question out to the rendering team to see if there's a path forward here, but otherwise we won't have support for print-reftest in downstream Chromium infra for now I'm afraid :(.