Support Out-of-flow "Page floats" for figures

[danielepolencic]

This is not a bug or a feature request, but rather a request for clarification.

Consider the following content:

The content overflows.
I'd like the red block to be always placed on a new page and I'd like to remove it from the natural flow of the document, like this:

I tried using FullPageBleed, but that does work. If I use the PageBreak, this is what I obtain:

Is there any way I could code a rule to reflow the content as per scenario 3?

[evnbr]

Yes, I believe what you're referring to is basically a "page float" as described here https://www.w3.org/TR/css-page-floats-3/

Right now bindery should support placing the red element on its own page, completely out of the text flow, using FullBleedPage. But it does not support (1) floating the element onto a new page, (2) continuing the text flow on the original page where the red element used to be, and then (3) continuing the text flow on the red element's page.

This is a super reasonable scenario, and something I hope to enable in the next major version of bindery.. part of the reason i was warning you off going too deep on fixing the rules implementation in #83 :)

[danielepolencic]

Understood. Is there a rough roadmap of what you plan to implement in the refactoring?

[evnbr]

I had a rough version working locally from a few months ago, just working around my day job to find the time to dig back in and finish. Hesitant to promise anything but I think it'll be over the line by beginning of january.

[danielepolencic]

I guess this is sort of related, but happy to open a new issue if it's not the case.
One common issue that I've found so far is this:

The HTML of that content is roughly equal to:

<div class="code-block">
  <nav>..</nav>
  <pre><code>
     <div> code line </div>
     ... one div per line ...
  </code></pre>
</div>

Ideally, I'd like the header to split only when it has at least 2 lines of code in the same page. Otherwise, it should continue in the next page.
I had a look at the code, and (at the moment) the shouldtraverse function works on one element at the time, whereas I think I need a way to decide to move to the next page based on surrounding elements too.

if (this.element has at least 2 lines of code && isOverflow()) {
  move everything to the new page.
}

I tried to come up with a sensible option on how to change the code to do that, and it's not trivial.
I think this code could be expanded to include a custom function that could decide if the element can be moved to the next region (but only after traversing and splitting).
The function could have the following signature:

function customCanSplit(originalElement: HTMLElement, proposedMoveableElement: HTMLElement): boolean {
 // here I can decide if proposedMoveableElement is worth splitting.
}

I don't think this is an easy change so I wanted to check with you first.

[evnbr]

I think what you're describing is similar to one of the earliest unresolved request with bindery (#8), which is about something like indesign "keep" options.

the area of code you linked to is very fragile and was supposed to be a band-aid. basically, to achieve the effect you're going for, we need to backtrack the traversal process entirely. Among other problems, backtracking should means undoing any changes from rules that have been triggered... but right now rules can have arbitrary imperative side effects that aren't tracked. the goal of my refactor is to make rules much more predictable so this sort of thing is possible, but even then will not be easy.