Thanks for quick reply and understanding (as always).
If you end up to just make api changes please don't make paging range to be different when page-break-inside | page-break-after. Purpose of paging api is to be low-level so don't ruin it by side effect magic heavy design :D I think best solution is just add more information: give border box range and margin box range. Of course if you want include this "auto range" feel free to do so but include raw data too please.
Our approach to this problemYes that's issue which we noticed as well. Approach we took was that page-break-before/page-break-after always create this "band" to next range where page-break is avoided. 'Next' means next in terms of coordinates (not structure) and including of course single text lines. This works very well in practice and even tough our pager is not perfect either this part is solid.
At the end page-break-after says that "put _something_ after me". If you have next element:
-paragraph => You got at least first line (and full para if inside: avoid)
-table => In general it will be drill down table -> thead -> tr -> th -> text row, so you have control as expected what is level where you avoid page-breaks.
-image (without inside: avoid) => We simply take full image and keep looking next avoid range. I think this may be "incorrect" in some sence but only realistic option with given information could be that random slice from image would be taken with first element but I cannot think any real situation where this would be actually wanted or messing another rules.
This work so far we agree that one "law of paged html" is: every element should have descedant element (or text row) with page-break-inside: avoid in every sub structure to be meaningful visual element. So this 'law' basicly says that last example about image without page-break-inside is style error. If you have counter example against this logic please challenge.
Btw just in case you have now warm and fuzzy feeling about your current solution here is some paging challenge for your current approach:
Code: HTML/ASPX
<style type="text/css">
.pre {
background-color: #AFA;
border: 1px solid #0A0;
height: 600px;
page-break-inside: avoid;
}
.container {
display: flex;
flex-direction: column;
justify-content: space-between;
height: 600px;
border: 1px solid black;
}
.container > * {
page-break-after: avoid;
page-break-inside: avoid;
border: 1px solid #A00;
background-color: #FAA;
height: 200px;
}
.container > *:nth-child(even) {
background-color: #AAF;
border-color: #00A;
}
</style>
<div class="pre">We want break after this</div>
<div class="container">
<div>A</div>
<div>B</div>
</div>
Remember that margins aren't only fundamental which moves elements. Btw approach I described solve this correctly.
As side note: flex box and grid layouts have another tricky property: structural order is NOT visual order. For example css rules order and flex-direction: column-reverse. We actually have some of these in our documents and we concluded that "page-break-after" means "do not break after this element" (visually) VS "stick with next element in structure" => so we still just think before and after in terms of coordinates.