As I'm investigating this, it seems that at least some implementations force a page break when a named page is invoked. The example works as expected in both PrinceXML and WeasyPrint without adding a page-break property.

I think GCPM is wrong here. CSS Pages says that implementations introduce a forced page break if necessary:

The page property is used to specify a particular type of page (called a named page
) on which an element must be displayed. If necessary, a forced page break is introduced and a new page generated of the specified type.

I would propose deleting the text " that also has a forced break property applied" from GCPM.

I don't think the the current wording is problematic - we've implemented it as currently specced, so I know it's possible to do (with bugs, but they're all ours). My reason for opening this issue was purely the lack of a visible forced break in the examples!

But I can see why it might look like a problem if we presume page always forces a page break. I don't think it's either necessary or correct to do this.

We have break-before: page if we want to force a page break, and as example 28 explicitly states, there are cases where multiple elements need to be on a landscape page but not each on their own landscape page. So I agree that the CSS-Pages definition is preferred, and I think Prince and WeasyPrint behaviour is incorrect in this instance. A page break is only necessary if explicit, i.e. with break-before: page, or if the current page is not of the correct type.

With your proposed change, the text is to read like this?

When the page property is applied to an element, a page group is created. The page group is the collection of all pages created by an instance of that element. When a new instance of the element is rendered, a new page group is started.

I think that may be problematic. Restarting the page group whenever you simply use the page property makes things ambiguous. For example:

table { page: landscape }

<table id="table1"> ... </table>
<table id="table2"> ... </table>
...
<table id="table95"> ... </table>

With this change to the text, you'd be restarting the page group for each table, and with multiple items specifying page potentially on the same page, it gets complex. For example, if "table1" ended halfway through the second page and "table2" started immediately after on the same page, is that page the first page in the "landscape" group or the second?

To sum up: I don't think a change to the spec is warranted. But those examples could use a break-before: page

The example works as expected in both PrinceXML and WeasyPrint without adding a page-break property.

WeasyPrint does not break pages between consecutive blocks with the same page value. This example:

<style>article { page: a } div { page: b }</style>
<article>a</article>
<div>b</div>
<div>b</div>
<article>a</article>

gives:

• page 1: a
• page 2: b b
• page 3: a

Page groups are not supported by WeasyPrint.

So I agree that the CSS-Pages definition is preferred

I agree too.

To sum up: I don't think a change to the spec is warranted. But those examples could use a break-before: page

👍

Also, the specificity of the "nth" selector is undefined. I presume :nth(5) is (0,1,0) and :nth(5 of A) is (1,1,0)?

Looks good to me.

I've added break-before properties to the examples, and fixed the selector typos.

This sounds terribly ungrateful - first, thank you for making the change! But always isn't a valid value for break-before. See https://drafts.csswg.org/css-break-3/#break-between

You could go for page-break-before: always, which is a compatibility option, or break-before: page which is the correct value.

However the intention is clear, which is the main thing. So thanks again.

The specificity of nth() is still undefined (I should have opened a separate issue for this, but as we're here...). I'm almost certain no-one implements this yet (we do but aren't yet public) so you've got no compatibility issues to worry about.

For reference, here's the text from css-page:

The specificity of page a selector is computed in a manner analogous to the computations defined in the Selectors module:

Count the number of page type names (= f)
Count the number of ':first' or ':blank' pseudo-classes (= g)
Count the number of ':left' or ':right' pseudo-classes (= h)

If you want @page:nth(1 of name) to have at least the same specificity as @page name, which I think is pretty hard to argue against, then there are exactly three possibilities left:

1. :nth(1), :nth(2n) and :nth(2n + 1) are all the same specificity as :first
2. :nth(1), :nth(2n) and :nth(2n + 1) are all the same specificity as :left
3. :nth(1) has the same specificity as :first, and :nth(2n) has the same specificity as :left. :nth(2n + 1) has a higher specificity than both of them.

I think option 2 is wrong - this selector should certainly override :left or :right. Between the others I don't really have a strong opinion, except to say that it does need a decision before anyone can implement it with confidence.

(and once decided, I'm more than happy to do a pull request with proposed wording Dave if it will help take the load off you)

The break-before issue should be fixed. GitHub has been strange today; the Overview.bs file appears to be correct but Bikeshed has not yet updated the editor's draft.