What happens when someone prints it? A print-output posture axis proposal (September 2026)

Quick Answer

Print-output posture is a proposed BuilderProof benchmark axis, drafted September 29, 2026, scoring what a generated application's records look like once they leave the screen. Printing is not a smaller screen. It is a different formatting model: a paged one, whose page size is chosen by the browser rather than by the application, whose default ink policy is allowed to discard background colour, and whose worst documented outcome is to clip content without saying so. This page proposes the axis, the seven signals, four postures and a ten-step protocol. It is a pre-registration, not a report. No builder is scored, named or placed here.

Why paper deserves its own axis

Almost every application these tools generate contains at least one artefact somebody eventually needs off the screen. An invoice. A booking confirmation. A packing slip. A consent form. A weekly report a manager takes into a meeting. The moment one of those leaves the browser it stops being laid out by the rules everyone tested it against, and starts being laid out by a model with different primitives and a different failure mode.

The distinction is not cosmetic. On screen, content that does not fit produces a scrollbar, and a scrollbar is a visible, recoverable failure: the reader scrolls. On paper there is no scrollbar. Content that does not fit is either pushed onto another sheet, scaled, or removed. The reader cannot tell which of those three happened, because the only artefact they hold is the output.

We think that gap is worth measuring for the same reason we measure the others: it is invisible in the place everybody looks, and it is entirely determined by code the builder emitted without being asked.

What "print-output posture" means here

For this axis, print-output posture is the degree to which the untouched emitted application produces a faithful, complete, readable artefact in a paged medium, with no human intervention. Three words carry weight.

Untouched. We measure the first emission. We do not follow up with "now make it printable". If a tool has to be told, that is the finding.

Faithful. Not pretty. We are not grading typography. We are asking whether every value visible on screen is still present, still legible, and still attached to the label that explains it.

Paged. The unit is a sheet, not a viewport. A layout that reflows is not thereby paginated, and the two are governed by different specifications.

The page size is not the application's decision

The CSS Paged Media Module Level 3 defines the size property for the page context, and its initial value is auto. The specification is explicit about what auto means: "The page box will be set to a size and orientation chosen by the UA. In the usual case, the page box size and orientation is chosen to match the target media sheet."

So unless the emitted stylesheet says otherwise, the dimensions every layout decision is measured against come from the reader's printer and the reader's operating system. A developer in one country tests against one sheet size, a reader in another receives a different one, and nothing in the application records that the two differ.

The specification also defines what happens when the page box and the sheet disagree. Section 7.4 gives a preference ladder: render at the indicated size on a larger sheet, rotate ninety degrees, scale to fit, slice across multiple sheets, and finally "Clip overflowed content (least preferred)." It adds that "The user agent may wish to consult the user before performing these operations." May wish to. The least-preferred outcome is silent removal, and the consultation that would surface it is optional.

Most decisive for a benchmark: the specification declines to define the general case at all. Section 3.2 observes that "some content may end up outside the page box", gives the example of a box wider than the page, and then states plainly that "A specification for the exact formatting of such elements lies outside the scope of this document." When the governing document declines to specify a behaviour, the behaviour is whatever each browser chose, and an application that relies on it has no contract to point at.

The default ink policy is allowed to throw away meaning

The second mechanism is not a layout rule at all. It is a colour rule, and it is the one that removes information rather than moving it.

MDN documents print-color-adjust as the property that "sets what, if anything, the user agent may do to optimize the appearance of the element on the output device", and says that by default "the browser is allowed to make any adjustments to the element's appearance it determines to be necessary and prudent". The permissive value is named economy, and MDN's description of it is the sentence this signal exists for: "when printing, a browser might opt to leave out all background images and to adjust text colors to be sure the contrast is optimized for reading on white paper. This is the default."

That is a sensible default. It is also, for a very common interface pattern, a silent loss of the only thing that distinguished two records. A status chip whose entire meaning is carried by a green or red background prints as an empty rounded rectangle. An alternating row stripe that told the reader which figures belonged to which line prints as an undifferentiated block. Nothing errors, and the reader has no way to know a distinction was ever there.

Two further details matter for scoring. The opposite value, exact, exists precisely for content "specifically and carefully crafted to use colors, images, and styles in a thoughtful and/or important way". But MDN also records that "Any options the user agent offers the user to allow them to control the use of color and images will take priority" over the page's declaration. So the application can ask, and the reader can overrule it, which is why we score a text fallback above a colour declaration.

There is an asymmetry worth recording in the same breath. The behaviour that causes the loss is the default and has been for as long as browsers have printed. The property that addresses it is marked Baseline 2025, newly available since May 2025. The mechanism for the problem long predates the standard mechanism for the fix, which is exactly the shape we found when we scored policy-controlled features earlier this month.

Where a page is allowed to break

The CSS Fragmentation Module Level 3 defines where the flow may be split, and the answer is: in more places than most layouts anticipate. Its Class A break points sit "Between sibling boxes" including, named explicitly, "table row group boxes, table row boxes". A table is therefore a thing that breaks between its rows by default, and a record rendered as a card is a block-level box that breaks between its children.

The property that prevents it, break-inside, has an initial value of auto. MDN records the property as available across browsers since January 2019, with the caveat that "Some parts of this feature may have varying levels of support", so this is broadly not a capability problem. It is a question of whether anything in the emitted stylesheet ever names the repeating unit.

The consequence is specific and easy to check: a line item whose description sits on one sheet and whose amount sits on the next is not a formatting complaint. It is two fragments that a reader has to reassemble, and that a scanner or a filing system will treat as two things.

The application cannot see whether any of this worked

The last mechanism is the one that makes the axis a one-actor problem rather than a testing problem.

MDN's reference for the print() method is short and unusually consequential. It "Opens the print dialog to print the current document", it "will block while the print dialog is open", and its return value is "None (undefined)." The document asks; the document is not told what happened. There is no resolved promise, no status, no cancellation signal.

The two events that look like they would close the gap do not. MDN says the beforeprint event "is fired when the associated document is about to be printed or previewed for printing", which means it cannot distinguish an actual print from a preview somebody opened and closed. Its guidance points the other way in any case: "In general, you should prefer the use of a @media print CSS at-rule, but it may be necessary to use these events in some cases."

So an application that records "invoice printed" when afterprint fires is recording that a dialog closed. It is not recording that paper exists.

The proposed rubric

Seven signals, weighted to 100. Weighting rewards the loss of information over the loss of neatness.

Why the colour row is weighted second and not fifth. It is the only signal where the failure destroys information rather than relocating it. A fragmented table is annoying and fully recoverable by the reader. A status chip that printed empty is unrecoverable from the artefact alone, and it fails in the direction where the reader does not know to ask.

Why the last row carries the least. Treating afterprint as confirmation is rare and easy to fix. It sits on the list because it is the point at which the illusion this axis is named for gets written into a database.

Four postures

• Level 0, Screen-only. No print rules exist. The paper copy is whatever the screen layout happens to produce when the page box is imposed on it.
• Level 1, Stripped. A print context exists and removes application furniture. Nothing governs pagination, colour or clipping.
• Level 2, Paginated. Fragmentation is controlled at the repeating unit, nothing is clipped, and references remain recoverable on paper.
• Level 3, Declared. The page box itself is declared rather than inherited, colour-carried meaning has a textual equivalent, and the artefact has its own addressable view.

The ladder is deliberately uneven, and the unevenness is the finding. Moving from 0 to 1 is a single block of CSS and perhaps twenty minutes. Moving from 1 to 2 requires knowing that a table row group is a break point, which is a fact about a specification rather than about the application. Moving from 2 to 3 requires making a decision about a page size that the application can never verify, because the sheet belongs to the reader.

How to reproduce it

1. Fix one brief containing a record-shaped artefact: a document with a header, a party, a dated list of at least forty line items, a status field, and a total.
2. Generate once, cold, with no follow-up prompt. Do not mention printing.
3. Serve the untouched export statically.
4. Control step, and it carries no information on its own. Print a marketing or landing screen first. It has no record to lose and will look acceptable at every posture, including Level 0. Record it so the comparison is visible, and do not score it.
5. Render the record view to a paged output at the default page size, then again at a second, different page size. Two sizes are the minimum that can distinguish a declared page box from an inherited one.
6. Count the values. Every label and figure present on screen is either present on paper or it is not. This is the primary measurement and it is a count, not a judgement.
7. Inspect every page boundary for a split record, and record how many of the forty line items are fragmented.
8. Re-render with the browser's background-graphics option off, which is the default state, and compare the state field against the same field on screen. If the state was colour-only, it is now blank.
9. Grep the emitted stylesheet for a print context, break-inside, print-color-adjust and an explicit page size declaration, and record each as present or absent. Presence is not a pass on its own; step 6 is.
10. Search the emitted source for afterprint and beforeprint and record whether either writes state.

Publish the brief, both page sizes, the per-signal result and the raw artefacts. A reader who disagrees should be able to re-run step 6 and get our count.

The named trap: the screen-only illusion

Every axis we propose names the illusion that hides its defect. Here it is the screen-only illusion, and its structure is that nobody prints their own application.

The person who could notice has no reason to look. They built the invoice, they can see it, and the artefact already exists on their monitor. The person who needs it on paper is a bookkeeper, a customer, a nurse, somebody filing a copy, and that person is outside the loop entirely. They receive the output rather than the system, so when a column is missing they do not know a column existed, and when a status chip is blank they do not know it was ever green.

The loop does not close from the other direction either, and that is what distinguishes this from an ordinary untested path. print() returns undefined. There is no event that means "a sheet came out of a printer". The application cannot count the times it happened, cannot sample the artefact, and cannot be told it was wrong. Even the developer's own check is compromised: they read the preview on a screen, at the one page size their own machine chose, already knowing what every colour meant.

Why this is not already covered

It is not responsive layout. Our responsive-layout proposal asks whether the layout adapts across viewport widths, and its harness is a viewport matrix rendered at six named pixel widths, with overflow detected by comparing rendered document width against viewport width. A paged medium has no viewport and no scroll, so that instrument has nothing to compare. The two also fail differently in kind: the responsive failure is overflow, which is continuous and reader-recoverable, and the print failure is fragmentation and clipping, which is discrete and not. They move independently in both directions. A build can reflow cleanly at the narrowest tested width and still split every record across a page boundary, and a build can overflow horizontally on a phone while printing correctly, because linearising for paper is a different rule from reflowing for a narrow screen.

It is not accessibility posture. Our accessibility proposal includes a contrast criterion, which asks whether two colours that are both present are distinguishable. This axis asks whether one of them is printed at all. Both directions occur: a palette can meet the contrast ratio perfectly and still lose the entire meaning of a status field when the background is dropped, and a palette that fails the ratio can print perfectly well if the state is also written as a word.

It is not data export. Our data-export proposal asks what happens when data leaves for another program, where the reader is a parser and the failure is a mis-read field. Here the reader is a person and there is no program at all, so the failure is a value that is absent rather than misinterpreted. A build can emit a flawless machine-readable export and have no print context whatsoever, and the reverse is equally possible. The two traps belong to the same family and are not the same mechanism, which is worth saying plainly rather than letting the resemblance pass. In the export case the developer is the reader, and the illusion holds because their own settings match the writer's. Here the developer is not the reader at all, and the illusion holds because the reader has no channel back.

There is also a composition worth stating rather than a boundary, because drawing a line here would be inventing one. The print dialog is browser chrome: the document opens it, cannot script it, cannot force it, and is not told the outcome. That is structurally the same situation our permission-refusal proposal describes for a capability prompt, with one difference that makes it stricter. A permission at least leaves a queryable state behind. A print leaves nothing at all, so there is not even a value to read back.

A second composition needs no link, only a sentence. Our money-arithmetic proposal scores whether an invoice total is exactly right. This axis scores whether the exactly right total reaches the paper. A figure computed in integer minor units and rounded under a single declared policy is still lost if it falls below the last line the page box had room for.

The tension this axis creates with itself

Signal 2 rewards declaring colour exact, and that is in direct conflict with why the default exists. MDN records the reason plainly: "If the output device is a printer, and to save ink, dark or extremely dense background images might be removed." An application that declares exact across a dark interface is asking a reader to spend a cartridge on a decision the application made for them, and MDN is equally clear that the reader's own setting wins anyway.

We resolve it by scope rather than by preference. The signal is not "declare exact". It is "do not let colour be the only carrier of meaning". A text equivalent satisfies it at zero ink cost and survives every setting the reader might choose, which is why the rubric's failing case names the missing textual equivalent first and the missing declaration second.

Why we are naming a pattern and not publishing placements

This is a pre-registration. The June 2026 output-quality round and the composite that depended on it were withdrawn on August 21, 2026 because the lab could not produce run artefacts for them, and nothing on this page restores a number. No builder is named on this axis, no builder is assigned a posture, and no cohort claim is made. When this axis is scored it will be scored on the protocol above, with the artefacts attached, after a community-edit window.

Limitations and open questions

• Signal 1 could punish the better design. An application with no record-shaped artefact at all, a dashboard, a chat, a game, has nothing to print and no reason to carry a print context. We score that a full pass on signal 1 rather than a blank, because absence of a need is not absence of quality. The rubric should not reward bolting a print stylesheet onto something nobody prints.
• Step 6 may not be automatable. Counting values on a rendered sheet is reliable for a fixed brief and brittle for arbitrary output. The protocol holds the brief constant for exactly this reason, and that limits how far the result generalises.
• Two page sizes is a floor, not a range. Real readers use more. We chose two because it is the minimum that can distinguish declared from inherited, and we would rather state a weak instrument than imply a strong one.
• We do not score typography or margins. A cramped but complete sheet passes. A beautiful sheet missing a column does not.
• The clipping outcome may be unobservable. Because the specification permits several responses and the consultation with the user is optional, a headless run may scale where an interactive one would clip. Results should record which response occurred rather than assuming one.
• The rubric may over-weight signal 3 at 16. A reader who receives a split table usually reassembles it without difficulty. The argument for the weight is that scanners and filing systems do not, but that is an assertion about downstream handling we have not measured.
• This is a rendered axis, not a documentation one. It cannot be scored by reading vendor docs, and it therefore inherits every reproducibility obligation that comes with running something.

Corrections and rubric edits are welcome, and the most useful contribution is a step 6 count from a real generated application: what the screen showed, and what came out of the printer.

BuilderProof editorial team. "What happens when someone prints it? A print-output posture axis proposal (September 2026)". BuilderProof, September 2026. https://www.builderproof.org/benchmarks/what-happens-when-someone-prints-it-print-output-axis-september-2026.

@misc{builderproof-what-happens-when-someone-prints-it-print-output-axis-september-2026,
  title  = {{What happens when someone prints it? A print-output posture axis proposal (September 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {sep},
  howpublished = {\url{https://www.builderproof.org/benchmarks/what-happens-when-someone-prints-it-print-output-axis-september-2026}},
  note   = {BuilderProof, builderproof.org}
}