Skip to content

safe-printable-inset META value proposal #233

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mstensho wants to merge 5 commits into
base: main
Choose a base branch
from
Open

safe-printable-inset META value proposal #233

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
47e1428
safe-printable-inset META value proposal
mstensho Jan 8, 2026
1931762
RFC number
mstensho Jan 8, 2026
333dc3b
Update safe-printable-inset.md
mstensho Jan 15, 2026
c7125b7
Update safe-printable-inset.md
mstensho Jan 20, 2026
6e2401e
We're using centimeters.
mstensho Mar 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions rfcs/safe-printable-inset.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
# RFC #233: Simulate safe printable inset

## Summary

We need a way of testing the [safe-printable-inset](https://github.com/w3c/csswg-drafts/pull/13190/files) property.

## Details

Most printers have a small region along each edge of the paper edges that's not
reliably printable, usually due to the printer's paper handling mechanism.
Authors can steer clear of such unprintable areas using the
`safe-printable-inset` property, which applies in `@page` and `@page` margin
contexts.

There should be a way for print reftests to test this, by simulating unprintable
areas.

One rather straight-forward solution would be a META value that sets the width
of the unprintable area on all four sides. For instance:

`<meta name="safe-printable-inset" content="[inset-specifier]">`

where `inset-specifier` is a numeric value. This values is in centimeters, to
match the other inputs to webdriver when printing. Using centimeters isn't
great, since they don't convert nicely into CSS pixels (unlike inches), but
since everything else is already in centimeters, better follow suit.

Why just one value for all four edges? Although many printers indeed don't
necessarily have a uniform unprintable area width along each of the four paper
edges (although many do), so that just providing one value for all is an
oversimplification of reality, printers may rotate the print output at their own
discretion. The user agent may therefore not be able to make assumptions about
which edge (long or short?) will be fed first into the printer, or what
orientation the sheet of paper has. Therefore using just one value (which should
represent the larger of the four) seems reasonable.
Comment on lines +28 to +35
Copy link
Copy Markdown
Member

@gsnedders gsnedders Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does leave us unable to test all the different at-rules the descriptor applies to — @page, @top-left-corner, @top-left, @top-center, @top-right, @top-right-corner, @right-top, @right-middle, @right-bottom, @bottom-right-corner, @bottom-right, @bottom-center, @bottom-left, @bottom-left-corner, @left-bottom, @left-middle, @left-top.

The spec says, along these lines:

Some printers don’t have a uniform unprintable area width along each of the four paper edges, and the printer may rotate the print output at their own discretion. The user agent may therefore not be able to make assumptions about which edge will be fed first into the printer, or what orientation the sheet of paper has. If the user agent cannot make such assumptions, only one will be provided (to be used on all 4 sides): The larger of these four values. Otherwise, if the user agent can trust that the four values are usable individually, and that no rotation is going to take place, and so on, each side of the page may have individual values.

It's not entirely clear to me from the spec how you go from potentially seventeen values (if specified in @page and all the margin at-rules) to only one, because the "larger of these four values" makes an assumption that you've already gone from seventeen to four.

Maybe starting with taking a single value is fine — but I could easily see us wanting to extend the metadata to take four values (potentially with semantics similar to the margin property?) to be able to actually test the case where the user agent can make assumptions about what edge will be fed first.

Copy link
Copy Markdown
Author

@mstensho mstensho Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're not unable to test any of those at-rules. The safe printable inset will just be the same along each of the four edges.

@page is adjacent to all four edges of a paper sheet, so all of margin-top, margin-right, margin-bottom and margin-left may be affected by page margin safety. @blah-corner is adjacent to two of the edges. The remaining at-rules are adjacent to only one edge. For e.g. @top-center, only margin-top may be affected by page margin safety. For @bottom-right-corner, margin-right and margin-bottom may be affected.

Here's a test (not yet landed): https://chromium-review.googlesource.com/c/chromium/src/+/7415846/4/third_party/blink/web_tests/external/wpt/css/css-page/safe-printable-inset-003-print.html