Intent to Ship: Named pages with page-orientation

[Morten Stenshorne]

Contact emails mste...@chromium.org Explainer https://github.com/mstensho/page-orientation/ Spec https://drafts.csswg.org/css-page-3/ TAG review https://github.com/w3ctag/design-reviews/issues/515 Summary Support the 'page' CSS property [1], along with named pages support (@page foobar {} selector). Also support the 'page-orientation' descriptor [2] for @page, with values 'upright' (initial value), 'rotate-left', or 'rotate-right'. [1] https://www.w3.org/TR/css-page-3/#using-named-pages [2] https://drafts.csswg.org/css-page-3/#page-orientation-prop Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/ByWuVBk1lFE/m/vAfiloyPBAAJ Risks

Interoperability and Compatibility 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/829028 Firefox: 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 Ergonomics 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. Activation 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.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Every platform that supports printing or PDF generation will have this Is this feature fully tested by web-platform-tests? No https://wpt.fyi/results/css/css-page/page-orientation.tentative.html?label=master&label=experimental&aligned Note that WPT doesn't really provide any support for printing tests, so for now we'll be adding those outside of WPT, i.e. in third_party/blink/web_tests/printing/ in Chromium. Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1053768 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5173237715566592

This intent message was generated by Chrome Platform Status.

[Manuel Rego Casasnovas]

On 15/06/2020 21:17, Morten Stenshorne wrote:
> Is this feature fully tested by web-platform-tests?
> No
> https://wpt.fyi/results/css/css-page/page-orientation.tentative.html?label=master&label=experimental&aligned
>
> Note that WPT doesn't really provide any support for printing tests, so for
> now we'll be adding those outside of WPT, i.e. in third_party/blink/web_tests/printing/ in Chromium.

This seems to have changed recently:
* https://github.com/web-platform-tests/rfcs/pull/41
* https://github.com/web-platform-tests/wpt/pull/21901

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]

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]

LGTM2.

Still looking for a reply regarding possibilities for test printing in
WPT inside Chromium.

> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a580adc0-d748-4058-8c6b-ddef28da3173n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a580adc0-d748-4058-8c6b-ddef28da3173n%40chromium.org?utm_medium=email&utm_source=footer>.

[Luiz Pereira]

+1! This is important for G Suite for the ability to print mixed-orientation documents. See blocking bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=835358

[Yoav Weiss]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/93ff25b9-9b6f-43ed-a5e3-ed338c0f157fn%40chromium.org.

[Stephen McGruer]

> 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]

> 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 :(.