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 4 commits into
base: main
Choose a base branch
from
+34 −0
Open

safe-printable-inset META value proposal #233

Changes from all commits
Commits
Show all changes
4 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
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
34 changes: 34 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,34 @@
# 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. The unit could be CSS pixels or
points. Using centimeters for anything here isn't a great idea, since they don't
convert nicely into CSS pixels (unlike inches). I suggest using CSS pixels.
Copy link
Contributor

@jcscottiii jcscottiii Jan 20, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Question: Is it worth it to enforce the usage of pixels here? (Or rather what's the risk if we don't enforce it?)

When new metadata is introduced, there's a risk of incorrect usage (e.g., typos, invalid values, or inappropriate units). For example, a value like content="2in" might be provided, even though the RFC suggests CSS pixels or points and discourages inches. The best way to mitigate this is to add automated checks. Other places that handled something similar:

  • RFC 163 (web_features) added a lint to ensure its new metadata didn't get out of sync with test files
  • RFC 158 (Variant name should be a non-zero length string) added a lint to forbid a problematic authoring pattern
  • RFC 211 (Support testdriver.js in other test types) proposed a lint to enforce correct usage with reftest-wait.

Copy link
Author

@mstensho mstensho Jan 20, 2026

Choose a reason for hiding this comment

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

I was thinking a unitless value, which is why I'm suggesting pixels. But I suppose we could require units (and even allow centimeters, for all those rounding error fans out there) to be specified as part of the value instead?


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.