Intent to Prototype: Named pages with page-orientation

[Morten Stenshorne]

Contact emails mste...@chromium.org Explainer https://github.com/w3c/csswg-drafts/issues/4491#issuecomment-594967467 https://bugs.chromium.org/p/chromium/issues/detail?id=1053768 Design docs/spec Specification: https://drafts.csswg.org/css-page-3/ https://github.com/w3c/csswg-drafts/issues/4491#issuecomment-594967467 TAG review 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://github.com/w3c/csswg-drafts/issues/4491#issuecomment-594967467 Motivation The Paged Media spec already defines a 'size' property [1], which naturally also can be used to set the orientation of a page. The new page-orientation descriptor is different, though, in that it just rotates all the layout, including any headers and footers. Printed pages may be presented together as a pamphlet or book, which essentially means that every page has the same size, and that the reader is supposed to turn the book or pamphlet 90 degrees when reading rotated pages. External formatting systems, such as word processors like Google Docs, may do page layout on their own and even push the output to a CANVAS, rather than individual DOM nodes. Such web-based word processors can also often support page sizings that are more advanced or specialized than what the user agent is capable of providing. For example, the rendering engines of Chromium and WebKit only have limited support for variable-size/shape pagination, and this feature can be used to work around such limitations. [1] https://www.w3.org/TR/css-page-3/#page-size-prop 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: No public signals Edge: No public signals Safari: No public signals 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 No perceived risks

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?label=master&label=experimental&aligned Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5173237715566592

This intent message was generated by Chrome Platform Status.

[Iwan Riza]

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKWZFm7F69wheP5dWDWZJZFasJA_EkMe4YBXmjOfyZDbmyP8rg%40mail.gmail.com.

[Manuel Rego Casasnovas]

On 25/03/2020 08:42, Morten Stenshorne wrote:
> 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]

These look like 2 separated features (I'm fine with just a single
intent-to-prototype anyway), but is there a clear relationship between
"page" property and the "page-orientation" descriptor? Or are they
independent features?

> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
> No
> https://wpt.fyi/results/css/css-page?label=master&label=experimental&aligned
> <https://wpt.fyi/results/css/css-page?label=master&label=experimental&aligned=>

There's some ongoing work in order to make possible to test printing
stuff like this in WPT:
https://github.com/web-platform-tests/rfcs/pull/41
I guess it'd be nice to use that somehow when doing tests for these
features if we want to share the with other browsers in WPT.

Bye,
Rego

[Morten Stenshorne]

Manuel Rego Casasnovas <re...@igalia.com> writes:

> On 25/03/2020 08:42, Morten Stenshorne wrote:
>> 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]
>
> These look like 2 separated features (I'm fine with just a single
> intent-to-prototype anyway), but is there a clear relationship between
> "page" property and the "page-orientation" descriptor? Or are they
> independent features?

Yes, they are 2 separate features, but closely related. The goal here is
to give individual pages in a document different orientation. In order
to do that, we need a way to specify orientation, and a way to separate
the content we want rotated (into designated pages). The two features
may be used separately. Named pages can be used for many things (since
there are many @page descriptors). Page orientation, on the other hand,
isn't very useful without named pages (unless you want to give all pages
the same orientation).

>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>> No
>> https://wpt.fyi/results/css/css-page?label=master&label=experimental&aligned
>> <https://wpt.fyi/results/css/css-page?label=master&label=experimental&aligned=>
>
> There's some ongoing work in order to make possible to test printing
> stuff like this in WPT:
> https://github.com/web-platform-tests/rfcs/pull/41
> I guess it'd be nice to use that somehow when doing tests for these
> features if we want to share the with other browsers in WPT.

Thank you for this information! That would be the ideal way to do it. In
the meantime, all we have is Chromium-internal test support for printing
(internal web tests and unit tests).

--
Morten Stenshorne, Software developer,
Blink/Layout, Google, Oslo, Norway

[Tab Atkins Jr.]

The 'page-orientation' descriptor doesn't yet live in the Page 3 spec,
but I have a PR up for it, implementing the CSSWG resolution that
Morten linked to: https://github.com/w3c/csswg-drafts/pull/4902