Print CSS for Long Tables: Test the Pages, Not Just the Screen

A long table can look excellent on screen and fail when printed. Fixed-height scrolling containers can hide rows, sticky headers can behave unexpectedly and wide columns can clip the content that makes the document useful. Treat print layout as a separate output with its own tests.

Mozilla’s printing guide describes print styles and related browser behavior. The examples below are a starting point, not a guarantee that every browser paginates the same way. Verify the target browser and the actual PDF or printed pages.

Start with a complete semantic table

Use a table header, body and appropriate header cells. Keep column meanings explicit and preserve useful captions or surrounding context. Print styling cannot recover data that was never rendered into the document.

If the screen uses virtualization, only a subset of rows may exist in the DOM. Create a supported print view containing the intended dataset rather than assuming the browser will print rows that are merely available through scrolling.

Define the print scope. A filtered report should say which period or filter it represents. Do not silently print the entire dataset when the user expects the visible filtered selection, or vice versa.

Remove screen-only constraints

A basic print stylesheet can remove interface controls and release the table from a scrolling viewport:

@media print {
  .screen-controls { display: none; }
  .table-scroll {
    overflow: visible;
    height: auto;
    max-height: none;
  }
  table { width: 100%; }
  thead { display: table-header-group; }
  tr { break-inside: avoid; }
}

Apply these selectors to the actual structure rather than adding generic class names without checking their effect. A fixed height on an ancestor can still clip content even if the immediate wrapper is corrected.

Do not hide errors, totals or essential annotations just because they occupy screen controls. Separate interactive buttons from the information a reader needs to interpret the printed report.

Choose a width strategy deliberately

Decide whether the table fits the intended paper size and orientation at a readable font size. Shorten nonessential labels, wrap descriptive columns and remove purely interactive columns from the print view where appropriate.

Avoid shrinking the entire table until text is technically present but practically unreadable. A very wide operational table may need a dedicated print layout with fewer columns and an explicit link or reference to the full digital record.

For identifiers and URLs, choose wrapping behavior carefully. Breaking a URL visually should not change the underlying link target. Ensure that a long unbroken token does not force every other column outside the page boundary.

Treat break rules as preferences, not magic

Avoiding a break inside a row helps ordinary rows stay together, but a row taller than a page cannot fit intact. The browser must still resolve that conflict, and different engines can behave differently.

Create a fixture with a multi-paragraph cell that exceeds one page. Decide whether the content should be split into smaller logical rows, moved into a detail section or allowed to continue across pages with sufficient context.

Also inspect whitespace before and after section boundaries. An overly broad avoid-break rule on a large container can push content to the next page or produce large gaps without improving readability.

Verify repeated headers and totals

Use a real header group and check that the target browser repeats it where expected. A header visible at the top of page one does not prove later pages identify the columns.

Keep totals distinguishable from ordinary rows and confirm they appear once in the intended location. A sticky screen footer or duplicated summary component can accidentally produce misleading repeated totals in print.

Include units and the reporting period in stable printed context. A reader holding page four should not have to guess whether a number is a quantity, a currency amount or a percentage.

Test the actual generated document

Use the target browser’s print preview and save a PDF through the supported user workflow. Inspect the first, middle and last pages, plus pages containing the longest cells and totals.

Check row count and a few stable identifiers against the intended dataset. Visual appearance alone can miss omitted rows, especially when a virtualized screen supplied only the first page of content.

Test both short and long datasets, empty results, Unicode text and a narrow numeric column containing its largest formatted value. A single carefully chosen demonstration table is not enough to establish a reliable report.

Keep output accessibility in scope

Readable print styling does not automatically guarantee a fully accessible PDF structure. If the deliverable requires accessible PDF tagging or a particular archival standard, verify that separately with suitable tools and expertise.

For ordinary printing, preserve sufficient contrast without depending entirely on colored backgrounds that a user may disable. Use text labels and clear table structure so meaning survives grayscale output.

Conclusion

Print layout needs its own complete dataset and pagination checks. Release scrolling constraints, handle long rows deliberately and inspect the generated pages before treating a good screen view as a finished printable report.