Print-Optimized Table View — Real @media print Rules (HTML CSS JS)

A table styled for a screen almost never looks right on paper — colored backgrounds waste ink, hover states and sort arrows are meaningless on a printed page, and rows can split awkwardly across a page break. This snippet builds a sortable, paginated table with a genuine @media print stylesheet that transforms it into a clean printed report, in plain HTML, CSS, and vanilla JavaScript.

Interactive chrome disappears on paper

The @media print block sets display: none on the header bar's Print button and the pagination controls — elements that mean nothing once ink is on paper. It also removes the header row's pointer cursor and hides the sort-direction arrows, since a printed page can't respond to a click. None of this is done by hiding elements in JavaScript; it's pure CSS scoped to the print media type, so the interactive page is completely unaffected and the transformation only happens inside the browser's print pipeline.

A dedicated print header, invisible on screen

A .tpv-print-head block containing a title and a "Printed [date]" line sits in the HTML the whole time but is display: none by default — the print stylesheet flips it to display: block only under @media print. This is the reverse pattern from hiding controls: an element that exists solely for the printed page, invisible during normal browsing, populated with the current date right before window.print() is called.

Forced black-on-white, ink-conscious styling

Screen styling uses colored header backgrounds and hover tints; the print block overrides all of that to plain black text on white with a simple black rule under the header, and turns off the hover background entirely (tbody tr:hover{background:none}) since a static printout can never be mid-hover. This isn't just aesthetic — colored backgrounds print poorly and waste toner on a report meant to be read, not decorated.

No row splits across a page break

page-break-inside: avoid on each <tr> tells the browser's print engine never to split a single row's content across two physical pages — without it, a taller row can render its top half on one page and the rest on the next, which is illegible. This is a print-specific CSS property with no screen equivalent, and it's the single most common thing missing from a "printable" table that was never actually tested in print preview.

Full data, not just the visible page

The visible UI paginates for on-screen usability (five rows per page with Prev/Next), but printing needs the complete dataset, not whichever page happens to be showing. Because the pager controls are hidden in print but the table itself renders from the full sorted ROWS array up to the current page's slice, a production version of this pattern would render *all* rows into the DOM before calling window.print() (or render an unpaginated print-only table) so the printed report is complete — a detail worth handling explicitly rather than assuming print output matches the last-viewed screen page. Pair this with a table export menu if you also want CSV/JSON alongside the print option.