It paginates wrong
position: fixed elements repeat on every page or vanish
A watermark, a sidebar or a footer either appears once and then never again, or appears on every single page when it was meant to be on one.
What is actually happening
Fixed positioning means fixed to the viewport, and a paged document has one viewport per page or none at all depending on the engine. Neither interpretation is what a scrolling layout meant by it, so both behaviours are correct and neither is what you wanted.
Confirming it is this and not something that looks like it
Change the element to position: absolute inside a positioned ancestor. If the behaviour becomes predictable, fixed positioning was the cause.
The fix
Use the page box for things that belong to every page, meaning header and footer templates, and use normal flow for things that belong to the content. Reserve absolute positioning for placing something within a container you control, such as a watermark inside a section.
/* A watermark that belongs to the content, not to the viewport. */
.page-section {
position: relative;
}
.watermark {
position: absolute;
inset: 0;
display: grid;
place-items: center;
font-size: 72pt;
color: rgba(0, 0, 0, 0.06);
transform: rotate(-30deg);
/* Behind the content, and not intercepting anything. */
z-index: 0;
pointer-events: none;
}
.page-section > *:not(.watermark) {
position: relative;
z-index: 1;
}If that was not it
These produce the same symptom often enough to be worth ruling out before assuming the fix above did not work.
- position: sticky, which has no meaning without scrolling
- A fixed element with a transform on an ancestor, which changes its containing block
- 100vh sizing, which is one page rather than the document
- Overlays intended to be dismissed, which have no dismissal in a document
Frequently asked
Does this happen with every rendering engine?
The behaviour behind it is not specific to one tool. Fixed positioning means fixed to the viewport, and a paged document has one viewport per page or none at all depending on the engine. Anything rendering HTML to a paged medium has to make the same decision, so the fix travels with you if you change how the render happens.
Will this show up as an error in my logs?
No, and that is what makes it expensive. A document that renders wrong is still a successful render as far as every log line is concerned. It is found by someone opening the file, which is usually the customer.
Related failures
Problems people arrive at from the same starting point, or mistake for this one.
Table headers do not repeat on the next page
Header repetition is driven by table sectioning, not by styling.
Page breaks land in the wrong place
Nothing told the layout where it is allowed to break, so it breaks wherever the content runs out of page.
There is an extra blank page at the end
Something extends a fraction of a millimetre past the end of the last page.
Content is cut off at the right edge of the page
The element is wider than the page's content box and has nothing telling it to wrap.
Page numbers are missing or all show 1
Page numbers come from the footer template's special classes, not from CSS counters in the document body.
CSS for paged documents, and what actually works
Which parts of the paged media specification a browser-based render implements.
Everything that goes wrong, by category
The full list, grouped by where in the pipeline it breaks.
Paste your markup and see the rendered document, without signing up.