This project styles an incident report for two rendering contexts. The article's HTML owns the facts and headings; CSS adjusts measure, controls, and page breaks.
CSS incident report project: readable on screen and on paper
How the rule works
On screen, keep the main report at a readable line length and allow evidence thumbnails to fit their container. In print, remove only the navigation and editing actions, not the finding or provenance. Headings should not be stranded at the bottom of a page, though exact pagination depends on the printer and final font metrics. The sample avoids color-dependent status because many print settings omit backgrounds. Pair it with the HTML report project, which supplies the case number, evidence descriptions, and links. A generated PDF is still a separate output that must be checked from the final rendering pipeline.
.incident-report { max-inline-size: 70ch; margin-inline: auto; line-height: 1.55; }
.incident-report img { max-inline-size: 100%; block-size: auto; }
@media print {
.site-navigation, .incident-actions { display: none; }
.incident-report { max-inline-size: none; margin: 0; color: #000; }
.incident-report h2 { break-after: avoid; }
.incident-report figure { break-inside: avoid; }
}Cost and verification
Screen rules are cheap; print review is the maintenance cost. Test an incident with several pages, a tall figure, and a long table. A break-inside hint may not be honored in every pagination context, so inspect the result rather than relying on the declaration alone. Keep the report's status explicit in text and verify that evidence URLs or identifiers remain usable from the paper copy.
Common Mistakes
- Do not hide source references merely because they complicate print layout.
- Do not assume break-inside guarantees one-page figures.
- Do not turn an unverified CSS print preview into an official archived record.
