Finding your way through a long document / Document control block
A document control block with owner, status and review date
Owner, status, issue date, review date and reference, gathered into one block near the front of a controlled document.
Why this block is harder than it looks
It is a small table of labelled values and its difficulty is entirely in what it is for: somebody needs to establish, in a few seconds, whether the document in their hand is current and who to ask about it. So the fields that answer that question have to be the prominent ones, and in most control blocks they are not, because the block is laid out as a uniform grid where a reference number and a review date get identical weight. A review date in the past is also the single most useful thing the block can tell anybody, and a uniform grid hides it.
The decisions that make it work
Reasons rather than a description of the code. Each of these is a choice that has a wrong answer, and the wrong answer is usually the default.
- Lead with status and review date. Those are the two fields that answer is this current, and everything else is secondary.
- Give status its own line at a larger size rather than putting it in the grid with the rest.
- Set the review date in full with the month as a word, so an out-of-date document is obvious rather than requiring the reader to parse a numeric date.
- Name a person or a role as owner, not a department. A document nobody owns is a document nobody updates.
- Keep the block together with break-inside: avoid and place it on the first page after the title, not in an appendix.
- Use the same field names as your document management system, so a value can be checked against the register without translation.
The fragment
Markup and the CSS it needs, and nothing else. It expects a document that already has a page rule and a base stylesheet, so paste it into one rather than opening it on its own.
<section class="doc-control">
<p class="status">Status: <strong>Issued for use</strong></p>
<dl>
<dt>Review by</dt><dd class="review">1 October 2026</dd>
<dt>Owner</dt><dd>R. Hall, Quality Manager</dd>
<dt>Reference</dt><dd class="ref">QMS-PR-014</dd>
<dt>Issued</dt><dd>14 March 2026</dd>
</dl>
</section>
<style>
.doc-control {
break-inside: avoid;
margin: 10pt 0 16pt;
padding: 8pt 10pt;
border: 0.5pt solid #ccc;
}
.doc-control .status {
margin: 0 0 6pt;
font-size: 11pt; /* the field that answers the question */
}
.doc-control dl {
display: grid;
grid-template-columns: auto 1fr;
column-gap: 10pt;
row-gap: 3pt;
margin: 0;
font-size: 9pt;
}
.doc-control dt { color: #555; white-space: nowrap; }
.doc-control dd { margin: 0; }
.doc-control .review { font-weight: 700; }
.doc-control .ref {
font-family: "IBM Plex Mono", ui-monospace, monospace;
white-space: nowrap;
}
</style>What breaks when it is built the obvious way
Laying every field out with equal weight in a two-column grid. The reference number, which nobody reads, then has the same prominence as the review date, which is the only field that tells anybody whether to trust the document.
How to prove it survived pagination
Show the page for three seconds and ask whether the document is current. If the answer takes longer, the status and review date are not prominent enough. Then confirm the block did not split across a page.
Where it sits in a finished document
This page is one block. The document it belongs to has a page rule, a base stylesheet, a header and everything else around it, and repeating all of that here would make thirty pages that say the same thing. The inspection checklist template is a complete file with this block already in it, so take that and change the fragment rather than assembling one from parts. The property doing most of the work here is covered on its own page, with the support caveats that belong there rather than here.
Frequently asked
Will this fragment work on its own?
Not as a whole document. It has no page rule, no margins and no base type, because those belong to the document rather than to the block, and duplicating them in every fragment would mean thirty copies to keep in step. Paste it into a template that already has them.
Why does it look right in a browser and wrong in the PDF?
Because a browser window is one continuous surface and a document is a stack of fixed rectangles. Nothing in a scrolling view exercises a page boundary, so every break rule in the fragment is inert until the content is paginated. Render the real thing with enough content to cross two or three boundaries, then look.
Do I need a special option on the render request for this?
No. Everything on this page is CSS and markup, which is your side of the boundary. What the render has to give you is a real page size with real margins, and after that the layout is decided by the stylesheet.
Other parts of a document
The blocks that sit next to this one, and one from the next group along so you are not sealed inside a single kind of problem.
A distribution list showing who received which copy
Names, roles and copy numbers of everyone the document was issued to, printed so a recipient can see who else has it.
A back cover that ends the document rather than trailing off
A final page carrying contact details, a document reference and nothing else, so a reader can tell the document has ended.
A reading guide that tells somebody which pages they need
A short block near the front saying what the document contains, which parts matter to which reader, and what to do next.
A pull quote that does not orphan the paragraph it came from
A short extract set large and apart from the body, used to break up a long document and signal what matters in it.
Inspection checklist, as a complete file
The whole document with this block already in place, ready to copy and change.
break-inside in paged output
The property carrying the weight here, with its real support status.
Every part of a document
The full list, grouped by the kind of problem the block poses.
Paste the fragment into the playground inside a page rule and see what it does at a real page size. That is the only way any of this gets confirmed.