HTML & CSS / Maintainable presentation systems / Lesson 18
Printing and paged media
Design a useful printed document with explicit content, readable pagination, and verified print behavior rather than assuming the screen layout transfers unchanged.
On this page
Lesson goals
- A printed page is another reading context
- Provide a focused printable handout
- Verify content completeness and export limits
A printed page is another reading context
Print has a finite page area, no interactive expansion, and output settings controlled partly by the user and printer. A sticky navigation bar, collapsed answer, or scrollable panel that works on screen may become missing or fragmented information on paper. Identify the printed task: an invoice, workshop handout, or article needs different supporting content. Keep meaningful headings and text in the document, and remove only controls that have no useful print role. Do not hide errors or qualifications merely to create a cleaner page. A printed record must still represent the actual information accurately.
Separate print rules from screen assumptions
Use @media print for print-specific presentation and @page for supported page-box settings such as margins. Browser headers, footers, paper choice, scaling, and background printing remain subject to implementation and user settings. Avoid claiming exact identical pagination across engines. Simplify multi-column screen layouts when a single reading column is more dependable, remove fixed positioning where it obscures content, and expose meaningful text that relied on overflow scrolling. Color may be absent, so preserve distinctions through words and borders where necessary. Test real print preview rather than relying on a screenshot of the ordinary screen stylesheet.
Provide a focused printable handout
The first example includes a screen-only local button and a printable article. Print rules remove the button, set readable dark text on a light surface, and choose page margins. The button is explicitly a non-submit local demonstration and has no fake print behavior. A production print control could invoke browser printing through reviewed scripting, but the content remains printable through the browser menu without that control. The article does not depend on a background image to identify its heading or topic. Check the browser’s background setting and monochrome output before depending on decorative fills to distinguish important sections.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Print handout</title>
<style>
body { font-family: system-ui, sans-serif; } @media print { .screen-only { display: none; } body { color: #000; background: #fff; } } @page { margin: 18mm; }
</style>
</head>
<body>
<main><button class="screen-only" type="button">Screen demonstration control</button><article><h1>Workshop handout</h1><p>Bring a text editor and keep these notes for reference.</p><h2>Preparation</h2><p>Review the semantic document examples.</p></article></main>
</body>
</html>
Print keeps the handout and omits the screen-only button.The print medium removes only the local control and retains article content. Page margins are requested without claiming identical printer output.
Treat fragmentation controls as constrained requests
break-inside: avoid asks the fragmentation algorithm to keep a box together where possible. It cannot guarantee that a box taller than a page will remain unbroken. Keep headings with following material where supported, repeat simple table headers as appropriate, and avoid giant unbreakable wrappers. The second example groups short sections and requests break avoidance, but its output description deliberately does not promise a fixed page count. Links lose their clickable affordance on paper; important destination information may need visible text or generated annotations, with care not to print secrets, very long tracking URLs, or meaningless fragment-only references.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Fragmentation preferences</title>
<style>
section { padding: 1rem; border: 1px solid; margin-block: 1rem; } @media print { section { break-inside: avoid; } h2 { break-after: avoid; } }
</style>
</head>
<body>
<main><h1>Session notes</h1><section><h2>Structure</h2><p>Use headings and meaningful elements.</p></section><section><h2>Presentation</h2><p>Adapt spacing and layout to the reading context.</p></section></main>
</body>
</html>
Print tries to keep each short section and its heading together.Short sections request intact pagination where feasible. The rules are fragmentation preferences and do not guarantee a particular page count.
Verify content completeness and export limits
Inspect print preview with different paper sizes, default margins, background settings, and representative long content. Confirm that hidden interactive panels do not remove required information and that tables, images, and long identifiers stay readable. A PDF generated by a browser is not automatically an accessible archival document merely because the original HTML used good semantics; PDF tagging, reading order, and downstream requirements need their own verification. Preserve the original accessible web version when suitable. Record browser version and print settings for reproducible defects, and verify actual content totals rather than judging success only by attractive pagination.
Common errors and fixes
Printed content is clipped inside a scrolling panel
- Why it happens
- Screen overflow and fixed dimensions were retained.
- How to fix it
- Review and simplify the print layout.
- Prevent it next time
- Check all required content in print preview.
A large section splits despite break-inside: avoid
- Why it happens
- The section cannot fit in the available page area.
- How to fix it
- Allow reasonable fragmentation or reduce the grouping.
- Prevent it next time
- Treat avoidance as a constrained request.
A PDF is declared accessible without inspection
- Why it happens
- HTML semantics were assumed to guarantee PDF tagging.
- How to fix it
- Verify the exported document’s structure and requirements.
- Prevent it next time
- Keep web and PDF accessibility checks distinct.
Check your understanding
1. What must change when a screen report contains a horizontally scrolling table?
Show worked solution
Verify that all required columns are available on paper. Consider a suitable paper orientation, simpler table, smaller but readable layout, or a separate print representation with the same data relationships. Merely hiding overflow can silently remove columns and invalidate the report.
2. Why should a print test include background printing disabled?
Show worked solution
Many users or print workflows omit backgrounds. Information expressed only through a colored fill may disappear, so preserve textual labels, sufficient text contrast, and useful borders or other cues. The printed task should remain understandable without requiring a particular personal printer setting.
Key takeaways
- Printing is a distinct reading context.
- Fragmentation preferences cannot override physical limits.
- Verify completeness and exported accessibility separately.