Here's the full situation (from Codex after a long struggle session):
Below is the summary I’d send Prince.
**Current Structure**
Current 2-col template shell is just [wrapper.html](/Users/cpr/dev/docpress-publisher/templates/document-basic/wrapper.html:11): one `<main class="document-body">...</main>`, no separate header block.
At render time, the first body `h1` is tagged as the title opener in [template.ts](/Users/cpr/dev/docpress-publisher/packages/render-core/src/template.ts:171) and [template.ts](/Users/cpr/dev/docpress-publisher/packages/render-core/src/template.ts:257).
Current relevant CSS:
```css
body.layout-two-column .document-body {
column-count: 2;
column-fill: balance;
}
body.layout-two-column .document-body > h1.document-title:first-child {
column-span: all;
break-after: avoid;
break-inside: avoid;
}
body.layout-two-column .document-body figure.docpress-float {
-prince-float: column;
width: 100%;
}
body.layout-two-column .document-body figure.docpress-float[data-float-width='full'] {
column-span: all;
-prince-float: page;
-prince-float-defer-page: 1; /* current workaround */
}
```
Live refs:
- opener `h1`: [styles.css](/Users/cpr/dev/docpress-publisher/templates/document-basic/styles.css:428)
- column float rule: [styles.css](/Users/cpr/dev/docpress-publisher/templates/document-basic/styles.css:479)
- full-width page float rule: [styles.css](/Users/cpr/dev/docpress-publisher/templates/document-basic/styles.css:487)
**General HTML Trigger**
This is the minimal pattern that reproduces the problem:
```html
<body class="layout-two-column">
<main class="document-body">
<h1 class="document-title">Report Title</h1>
<p>Opening prose...</p>
<figure class="docpress-float docpress-table">
<table>...</table>
<figcaption>Table 1...</figcaption>
</figure>
<h2>Section</h2>
<p>More prose...</p>
<figure class="docpress-float docpress-table" data-float-width="full">
<table>...</table>
<figcaption>Table 2...</figcaption>
</figure>
<figure class="docpress-float docpress-table">
<table>...</table>
<figcaption>Table 3...</figcaption>
</figure>
</main>
</body>
```
The opener-jump bug can happen even without the earlier column float. The mixed-queue starvation bug becomes much more obvious when both column floats and page floats are present.
Our best real repro fixture is [comprehensive-tables.md](/Users/cpr/dev/docpress-publisher/fixtures/comprehensive-tables.md:1) in two-column.
**Observed Failures**
Without `-prince-float-defer-page: 1`, a later full-width page float can appear above the opener `h1` on page 1.
Concrete observation from `comprehensive-tables`:
- page 1 text began with table content and `Table 2...`
- only after that did `Comprehensive Tables Fixture` appear
Also, when mixed column floats and page floats are present:
- later page floats can consume earlier page slots
- earlier column floats then get pushed far later
- in our fixture, `Table 3` could end up at the very end for this reason
So there seem to be two related problems:
- page float can leap ahead of preceding non-float opener content
- page floats can starve earlier column floats
**What We Tried**
1. Original structure had a separate wrapper header above `.document-body`, and the body `h1` was hidden in 2-col. That definitely failed: full-width page floats could appear above the visible title/header.
2. We removed the fake wrapper header and used the real first body `h1` as the opener, with `column-span: all`. This simplified the structure, but controlled testing showed it did not fix the core bug by itself.
3. Controlled proof: after the real-`h1` change, removing `-prince-float-defer-page` still let `Table 2` jump above the opener. So the structural change was not causal.
4. `-prince-float-policy: in-order` alone did not fix the opener jump.
5. `-prince-clear: page` / `-prince-clear: end` on the opener `h1` did not fix it.
6. `-prince-clear: end` on the full-width float, with `in-order` and no defer, did not fix it.
7. Explicit `top/page/column-span: all/in-order/clear:end` on the full-width float still failed.
8. `-prince-float: bottom` kept the opener clean, but broke later ordering badly; e.g. `Table 5` could appear above `Table 4`.
9. `bottom + in-order` still broke later ordering.
10. `-prince-float-defer-page: 0` or no defer reproduced the bad behavior immediately.
11. `-prince-float-defer-page: 1` is the only thing we found that reliably keeps page 1 from being preempted by the full-width page float.
**What `defer-page: 1` Fixes And What It Breaks**
It fixes:
- page 1 opener protection
It does not fix:
- mixed page-float vs column-float queue behavior
Its downside:
- it is blunt/global
- every full-width page float is deferred a page
- locality gets worse
- earlier column floats can still get starved later in the document
So it is a workaround, not a real solution.
**What Seems Fundamental**
The root issue appears to be the interaction between:
- `-prince-float: page`
- multicol layout
- ordinary in-flow opener content
- mixed page-float and column-float queues
The working theory from our tests is:
- page floats are not sufficiently constrained by preceding non-float content at the top of a multicol container
- `in-order` seems to constrain float-vs-float ordering, but not page-float placement relative to earlier non-float opener content
- and possibly not enough across mixed `page` and `column` float queues either
In short:
- `column-span: all` on the opener is not a hard barrier to later page floats
- `-prince-float: page` can still leapfrog it unless deferred
- mixing page floats and column floats produces queue starvation/reordering effects beyond the opener problem
**The Exact Prince Question**
Is there a way to express:
“Allow a full-width page float to appear as early as possible, but never before preceding in-flow opener content at the top of the first multicol page, and without globally deferring all later page floats by one page?”
And second:
“Does `-prince-float-policy: in-order` constrain `page` floats relative to earlier `column` floats and earlier non-float content, or only relative to other eligible floats?”
That is the actual gap we could not solve with CSS.
) have been thrashing for hours trying all kinds of things, with only -prince-float-defer-page: 1 sorta working but having bad side effects when applied to all floating objects.