Named pages with page-orientation

[mstensho]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Part of CSS paged media
• Specification or proposal URL:
  https://drafts.csswg.org/css-page-3/#page-orientation-prop
  https://drafts.csswg.org/css-page-3/#using-named-pages
  Explainer: https://github.com/mstensho/page-orientation/
  TAG review: CSS page-orientation descriptor w3ctag/design-reviews#515

Other information

I'm asking for Mozilla's position on the new page-orientation descriptor to be used in @page rules. This is currently being prototyped in Chromium, along with support for named pages. The page-orientation descriptor isn't very meaningful without support for named pages (unless we're happy with @page :first, @page :left, etc.), so we're doing both at the same time.

Chromium intent to prototype: https://chromestatus.com/features/5173237715566592

[dbaron]

I think this basically seems reasonable to me. The proposed usage is absolutely a hack -- but at the same time, it seems like a very simple feature that would probably be useful even in the presence of widespread support for size (which is a more complicated feature).

I'm curious if you've shared the explainer with the CSSWG -- I wonder if they'd agree with this proposed usage of the feature.

(That said, named pages are a rather more complicated feature, and I've never been sure how size on pages is actually supposed to work in the presence of printer settings and actual paper availability.)

I'm curious if @MatsPalmgren @jwatt @dholbert @emilio @heycam have other opinions here.

[mstensho]

I shared the explainer at w3c/csswg-drafts#4491 (where this descriptor was discussed) just now.

[mstensho]

... and thank you for the feedback!

[emilio]

I tend to agree with @dbaron here: It seems like a reasonably straight-forward thing.

I think named pages are the thing that don't seem so straight-forward to me, and probably needs a bit more thought... Sorry in advance because I wrote the following while going through the spec, and I may have answered my own questions, but I'd rather leave them here in case I didn't :)

Do I understand correctly that the intention of the named pages spec is that setting page also effectively behaves like having break-{before,after}: page? Or would it behave like that only if the current page type the element would be laid out in doesn't match? The spec just says:

If necessary, a forced page break is introduced and a new page generated of the specified type.

But "If necessary" doesn't seem all that precise to me (but maybe it's just that's late and I'm not a native English speaker). I guess it tries to specify the later behavior I described?

In any case, why is it needed to have the "auto resolves against ancestors" behavior? Is it just so that if you break at a page boundary inside an element with an auto page type, you get a page of the "right" type from the ancestor? I guess that would make sense, and then it's just a bit weird wording in the spec, or it maps weirdly to my mental model of how I'd implement this :)

But anyhow I think this seems reasonable over-all.

As a bit of a drive-by, page as a descriptor name seems like extremely general... I feel that it should maybe be called something more descriptive like page-type or something like that? Not sure if that is changeable at this point, guess it depends on what print engines do or what not... But I wonder if anyone else in this thread has opinions :)

[heycam]

As a feature for controlling print preview or PDF output page orientation, this seems OK. David's right in that it is a "hack" to support landscape pages in UAs that don't support the size descriptor, but it's a small and fairly self-contained feature, so I don't have too much of a problem with it.

The only thing I want to point out is that this feature is not good for automatically placing a large chart or table in the middle of the document, since selecting a new named page using the page property forces a page break, which means that as the document author you must be aware of where the page break would normally be, to avoid blank space on the page before.

For example if you had:

<style>
@page rotated {
  page-orientation: rotate-right;
}
.large-figure {
  page: rotated;
  writing-mode: sideways-lr;
  display: grid;
  place-items: center;
}
</style>
<p>contents contents contents ...</p>
<div class="large-figure">
  <table>...</table>
</div>
<p>more contents contents contents ...</p>

then unless you're very lucky, the page break that occurs just before the table is likely to leave some of the previous page blank, depending on its content. Obviously this kind of use case is what page floats are for, but I think it demonstrates that page-orientation is probably only useful if (a) you would have a page break immediately before the rotated page anyway (perhaps it's the start of an appendix with large tables), or (b) you are in significant control of the layout of the document, and have basically done layout yourself so that you know exactly where the page break should be.

As long as we are accepting that this does not solve the page float use case (and the awkwardness that comes from using writing-mode etc. to orient the content) it seems fine.

As a bit of a drive-by, page as a descriptor name seems like extremely general... I feel that it should maybe be called something more descriptive like page-type or something like that? Not sure if that is changeable at this point, guess it depends on what print engines do or what not... But I wonder if anyone else in this thread has opinions :)

PDF formatters have a long history of using page as the property name for selecting between named pages, so despite being a bit general, it's probably best to stick with it.

[mstensho]

Thank you for the feedback!

@emilio For a forced break to happen when using 'page', the value needs to differ from its "surroundings". Only then it's necessary. :) The concept of the 'start page' and 'end page' values is what helps this make sense. Named page breaks require class A breakpoints, very similar to forced breaks, so that if they are specified elsewhere (at a first-child, for instance), it gets propagated up. Here's a test that might help: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/printing/page-orientation-propagated.html - in this case the first page property in the document is specified on the first DIV, for instance. This isn't a valid class A breakpoint (it's a first-child), so it gets propagated all the way up to the root. This doesn't result in a break, but it does cause the first page to be rotated.

@heycam Right - this isn't suitable for providing support for page floats, and being in significant control of the layout of the document is typically crucial for page-orientation, especially on the pages that are rotated.