See

https://www.print-css.rocks/lesson-running-elements.html

It is debatable if this is a bug or a feature or a valid interpretation of the page-break-before semantics

Thanks, that is a little weird, we will take a look.

Great site, by the way!

The document in question has a positioned box before the element with page-break-before. The behaviour for this isn't clearly defined by CSS (in that it depends on where the positioned element belongs in the box tree, and the CSSWG decided not to work on specifying this), but Prince's current behaviour conforms to my best reading of the specs as currently written.

Even if that turns out not to be the case, it seems reasonable to change the example to match more standard practice where it is an element for the chapter that has page-break-before set, and where the chapter title is a descendant of the element for the chapter.

If it's desired to change the specs on this point, then a starting point to look at would be the css-break spec (http://www.w3.org/TR/css-break-3/, or the Editors' Draft at http://dev.w3.org/csswg/css-break/).

For example, maybe change the language for "first-child box" and the definition of breaks between adjacent siblings to count only in-flow boxes.

A related possibility would be to change the behaviour of page-break-before:always so that it doesn't result in an empty page when only certain types of boxes precede that page-break-before:always box. (This might or might not involve a change to css-page in the last paragraph of the Page Progression section, discussing suppressing an initial empty page.)

Another possibility (I think less promising) would be to supply a definition of the box tree that made the position:running() element not generate a box that's a previous sibling of the box generated by the break-before element. I think that the addition of the "out-of-flow elements" paragraph to http://www.w3.org/TR/CSS2/tables.html#anonymous-boxes (against some resistance) is evidence that browsers do want at least position:fixed elements to generate such a previous sibling; and I imagine that position:running() should behave much like position:fixed.

I am taking the users prospective and say: independent of what the standard says (or not says): make the behavior consistent with other related tools. Interoperability is a major issues. If the standard is weak or has issues: report it to the standard committee...or discuss interoperability issues with other vendors.
Interoperability is king.

I agree that more discussion among implementers would be valuable. (There is already a little.) I'll have a look into what's practical for advancing interoperability.

I have already reported to the CSS committee the undefinedness problem I mentioned above. From my understanding so far, the main remaining problem is that the implementations you tested other than Prince don't implement what's written.

Thinking some more about what the spec ought to say if we were to change it: If position:running() in the example were changed to position:absolute, then I think users would want the subsequent page-break-before:always element to go to a new page (page 2). I also tend to think that position:fixed would be expected to behave similar to position:absolute (because CSS considers both to be forms of absolute positioning, and they behave the same as each other in most respects in CSS); and also that position:running() should behave like position:fixed (as both involve taking an element out of the normal flow and (potentially) repeating it on multiple pages). So, although I think we could decide to break either of those equalities, I can also see an argument that the existing approach in the spec is the right one, suggesting that it might be PDFReactor and AntennaHouse that would change, rather than the specs and Prince changing.

If instead Prince and the CSS specs were to change to match either PDFReactor or AntennaHouse (or both if we're lucky), then that involves discovering what their behaviour is (whether by testing or because they tell us). If convenient, could you try changing position:running() in turn to position:absolute and position:fixed ? These tests are applicable to most print UAs; I wonder how much consistency we have even without position:running().

I've also constructed some tests on anonymous table object creation for positioned elements (which I might post later if it looks relevant), though the specified behaviour for these probably won't change.