Nakodo ships 154,384 bytes of CSS for its 76 public pages. I grepped it for print rules:

$ grep -c '@media print' nak.css 0 $ grep -c '@page' nak.css 0 $ grep -c 'color-adjust' nak.css 0

Nothing. Which is not because media queries never occurred to us. The same file has 13 blocks for prefers-reduced-motion, 6 for forced-colors and 9 for hover: hover. Somebody thought about vestibular disorders, Windows high contrast mode and touch devices, and nobody thought about paper.

So I printed all 76 pages and measured what comes out.

496 sheets

Page.printToPDF over CDP, A4, 0.4 inch margins, backgrounds on:

76 pages measured total 496 sheets of A4 52 MB of PDF median 7 sheets per page longest /how-it-works 10 / 9 /guides/instagram-and-tiktok-outreach-templates 9 /glossary 8 /privacy 8 shortest /blog, /alternatives, /tiktokers, /instagrammers 3 each

Then I did the same run with header and footer removed from the DOM first:

417 sheets 42.1 MB

79 sheets of A4, 16 per cent of the whole site on paper, is the navigation. That is one full sheet per page and a bit, and it is not surprising once you measure the footer: it is 501 pixels tall at print width, carries 36 links, 23 inline SVGs and 302 path elements, and it is on all 76 pages. It contains a drawn landscape with a tree, a bird and a YouTube logo. Every single printout ends with it.

The header prints too, including the "Open the app" button and a hamburger menu icon, which on paper is a picture of a button that cannot be pressed next to a picture of a menu that cannot be opened.

337 FAQ answers that do not print

Our FAQ is a details element, 337 of them across 66 of the 76 pages. I counted how many are open in the delivered HTML:

$ grep -o '<details' *.html | wc -l 337 $ grep -o '<details[^>]*\bopen\b' *.html | wc -l 1

One. So a printed copy of how to find YouTube influencers carries five questions and no answers, and a printed copy of pricing carries twelve of its thirteen the same way. The questions are real questions people ask, the answers are the part worth keeping, and the paper has the headings only.

The fix I expected to use is the one every print stylesheet has had since about 2006:

@media print { details > *:not(summary) { display: block; } }

That no longer works. I tested it on the live page by applying each candidate rule and asking the browser directly:

const d = document.querySelector("details:not([open])"); const a = [...d.children].find((c) => c.tagName !== "SUMMARY"); a.checkVisibility({ checkOpacity: true, checkVisibilityCSS: true }); 
no rule false details > *:not(summary) { display: block } false details::details-content { content-visibility: visible } true

A closed details no longer hides its children with display: none on the children. It hides a generated box, ::details-content, with content-visibility: hidden, which is why the child can report a 116 pixel height and still not be visible. display: block on something inside a hidden container does nothing at all. The modern rule is one line and it targets the pseudo element.

Setting the open property in JavaScript on beforeprint also works, but only after a frame has passed. My first measurement said it had failed, because I read checkVisibility() in the same tick I set open, which is a good way to publish something untrue. Give it a frame and it is visible.

The part that would actually embarrass us

Chrome's print dialog has a "Background graphics" checkbox and it is off by default. Backgrounds off means background-color is not painted. It does not mean color is ignored.

So I counted, on every one of the 76 pages, the text runs whose colour is near-white and whose nearest painted ancestor background is dark:

342 white-on-dark text runs across 76 pages every page has at least 2 median 4 most, the home page, has 37

Every page has at least two because of the "Open the app" button in the header and its twin in the footer. On paper, with the default settings, those print as nothing: white text, no fill, white paper.

/pricing has twelve, and they are not a button. Our recommended plan card is inverted: dark fill, white text, which is how the design says "this is the one". With backgrounds off, the entire Pro card prints as a faint ghost. The plan name, the price, the seven feature lines, all of it. The Free card below it, which is a white card with a border, prints perfectly.

I simulated it by stripping background painting on the live page:

const s = document.createElement("style"); s.textContent = "*,*::before,*::after{background-color:transparent !important;background-image:none !important}"; document.head.appendChild(s);

The result is a pricing page where the free plan is crisp and the paid plan we recommend has dissolved. Nobody designed that. It is what you get when the only thing holding an element together is a fill, and you hand the document to a medium that treats fills as optional.

This is the real argument for print-color-adjust: exact, and the better argument for not depending on a fill at all. A card that is a border plus dark text survives every medium. A card that is white text on navy survives exactly one.

Where the pages break

With no print CSS there is nothing telling the browser where a page may be cut. I approximated the pagination by laying the pages out at print width (717 CSS pixels inside A4 margins) and looking for boxes that cross a 1,045 pixel boundary:

/ 8 estimated sheets 11 boxes split 4 of them inline SVGs /pricing 5 8 boxes split 1 heading orphaned /guides/how-to... 7 5 boxes split 1 heading orphaned /privacy 8 4 boxes split 3 headings orphaned

An orphaned heading here means a heading that starts within 120 pixels of the bottom of a sheet, so it prints at the foot of one page with its section on the next. On /privacy that happens to "2. Cookies", "7. If you run a business" and "10. YouTube API Services", each sitting between 31 and 66 pixels from the bottom edge. break-after: avoid on headings costs one line and fixes all three.

The estimate is an estimate: real pagination pushes unbreakable boxes down, which is why the home page measured 8 sheets by arithmetic and printed 9. Tables, at least, are fine. Every table on every page fits inside a single sheet at print width, so the 52 table scrollers that need horizontal scrolling at 320 pixels need nothing at all on paper.

Links are the other thing paper cannot do

There are 5,184 href attributes across the 76 pages. On paper, every one of them is coloured text with no address attached, because we have no rule like this:

@media print { a[href^="http"]::after { content: " (" attr(href) ")"; } }

Our guides open with an "On this page" list of up to seven anchor links, which on paper is a list of section names in link blue that go nowhere, under a heading that promises navigation. That one I will fix by hiding the list in print rather than by printing seven #fragment URLs next to it.

I am not going to print every URL either. 5,184 of them, most internal, would double the length of some pages to tell a reader that /pricing is at /pricing. External links are the ones worth the ink, and there are only 19 of those on the whole site.

The print stylesheet I am writing

Eleven lines, and every one of them came out of a measurement above:

@media print { header, footer nav, .toc, .cta { display: none; } details::details-content { content-visibility: visible; } h1, h2, h3 { break-after: avoid; } .plan-card { print-color-adjust: exact; } a[href^="http"]::after { content: " (" attr(href) ")"; font-size: 0.85em; } }

That takes the site from 496 sheets to something closer to 410, puts 337 answers back on the paper they were missing from, stops the recommended plan from disappearing, and keeps the one footer line anybody printing a page actually needs, which is who we are and what the YouTube logo is doing there.

None of this was a bug anyone would have reported. Printing a marketing site is rare, and the pages that do get printed are the ones somebody is taking into a meeting: pricing, terms, a guide. Which are, with the precision these measurements usually have, exactly the three that lose the most when the ink hits the paper.