safe-printable-inset META value proposal by mstensho · Pull Request #233 · web-platform-tests/rfcs

mstensho · 2026-01-08T14:22:29Z

Spec: https://drafts.csswg.org/css-page-3/#page-margin-safety

jcscottiii

LGTM. I only have one question.

jcscottiii · 2026-01-20T14:26:24Z

rfcs/safe-printable-inset.md

+
+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.


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.

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?

Typos

gsnedders

Mostly my question is "how would we hook this up to the style engine", because somehow we have to go from the meta element to this impacting print style and output.

Most of the time we're using WebDriver to communicate with the browser; does it therefore make sense to add something to the WebDriver print command that specifies the safe printable inset? My gut is yes?

mstensho · 2026-01-27T17:34:20Z

Here's something I hacked together for testing.

https://chromium-review.googlesource.com/c/chromium/src/+/7415241

Does this answer your question?

mstensho · 2026-02-03T10:06:56Z

@gsnedders Are you asking whether we should add something to https://w3c.github.io/webdriver/#print-page ? I think that might be a good idea. It could be specified as a single inset value, or it could be a rectangle within pageWidth x pageHeight.

Is everything in centimeters here? That's rather bad, since they don't convert nicely to CSS pixels. But I suppose we need to follow suit.

gsnedders

@gsnedders Are you asking whether we should add something to https://w3c.github.io/webdriver/#print-page ?

Yes, which appears to be what the draft CL does. Can you please make a PR against WebDriver, and get consensus there first?

I think that might be a good idea. It could be specified as a single inset value, or it could be a rectangle within pageWidth x pageHeight.

It should allow both separately, I'd expect.

Is everything in centimeters here? That's rather bad, since they don't convert nicely to CSS pixels. But I suppose we need to follow suit.

Yes, which is… deeply unfortunate, I agree. Though to be fair, A4 paper doesn't convert nicely to CSS pixels either. :)

mstensho · 2026-02-04T07:31:24Z

@gsnedders Are you asking whether we should add something to https://w3c.github.io/webdriver/#print-page ?

Yes, which appears to be what the draft CL does. Can you please make a PR against WebDriver, and get consensus there first?

What's the name of the repo?

I think that might be a good idea. It could be specified as a single inset value, or it could be a rectangle within pageWidth x pageHeight.

It should allow both separately, I'd expect.

I really think one of them should be enough. But that can be discussed there.

Is everything in centimeters here? That's rather bad, since they don't convert nicely to CSS pixels. But I suppose we need to follow suit.

Yes, which is… deeply unfortunate, I agree. Though to be fair, A4 paper doesn't convert nicely to CSS pixels either. :)

Hey, A4 doesn't even convert nicely to centimeters. The height being 21cm * sqrt(2). :-p

For print reftests, check <meta name="safe-printable-inset"> to simulate an unprintable region along the paper edges. The `content` attribute takes a non-negative number, which is the safe printable inset specified in centimeters. Only implemented for executorwebdriver. Spec discussion: w3c/csswg-drafts#11395 Spec change: w3c/csswg-drafts#13190 RFC: web-platform-tests/rfcs#233 For background, see https://drafts.csswg.org/css-page-3/#printable-area

mstensho · 2026-02-25T07:31:08Z

wptrunner and webdriver code changes PR here: web-platform-tests/wpt#58030

This is for testing the `page-margin-safety` descriptor in `@page` and page margin box contexts. Spec discussion: w3c/csswg-drafts#11395 Spec change: w3c/csswg-drafts#13190 RFC: web-platform-tests/rfcs#233 wptrunner and webdriver code changes: web-platform-tests/wpt#58030

mstensho · 2026-02-25T07:47:34Z

webdriver spec change: w3c/webdriver#1950

mstensho · 2026-03-04T07:25:05Z

The css-page spec changes have landed, and I've updated the description here accordingly.

mstensho · 2026-03-09T09:43:06Z

Updated the RFC to use centimeters.

Please have another look.

Thank you.

mstensho · 2026-04-07T06:22:24Z

I went with a single value for all four edges for now. As pointed out in the spec, the browser usually cannot make assumptions about which edge ends up where.
Can this be reviewed now?

jcscottiii · 2026-04-07T15:37:22Z

We talked about this today. @gsnedders is commenting on w3c/webdriver#1950 and w3c/csswg-drafts#11395

gsnedders · 2026-04-07T16:24:09Z

rfcs/safe-printable-inset.md

+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.


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.

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

mstensho and others added 3 commits January 8, 2026 15:19

safe-printable-inset META value proposal

47e1428

RFC number

1931762

Update safe-printable-inset.md

333dc3b

mstensho marked this pull request as ready for review January 15, 2026 08:48

jcscottiii approved these changes Jan 20, 2026

View reviewed changes

Update safe-printable-inset.md

c7125b7

Typos

gsnedders reviewed Jan 27, 2026

View reviewed changes

gsnedders requested changes Feb 3, 2026

View reviewed changes

mstensho mentioned this pull request Feb 25, 2026

Add plumbing for safe printable inset to wptrunner and webdriver. web-platform-tests/wpt#58030

Open

mstensho mentioned this pull request Feb 25, 2026

Add safePrintableInset parameter for printing. w3c/webdriver#1950

Open

We're using centimeters.

6e2401e

mstensho requested a review from gsnedders April 7, 2026 06:22

gsnedders reviewed Apr 7, 2026

View reviewed changes

Conversation

mstensho commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jcscottiii left a comment

Choose a reason for hiding this comment

Uh oh!

jcscottiii Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mstensho Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

gsnedders left a comment

Choose a reason for hiding this comment

Uh oh!

mstensho commented Jan 27, 2026

Uh oh!

mstensho commented Feb 3, 2026

Uh oh!

gsnedders left a comment

Choose a reason for hiding this comment

Uh oh!

mstensho commented Feb 4, 2026

Uh oh!

mstensho commented Feb 25, 2026

Uh oh!

mstensho commented Feb 25, 2026

Uh oh!

mstensho commented Mar 4, 2026

Uh oh!

mstensho commented Mar 9, 2026

Uh oh!

mstensho commented Apr 7, 2026

Uh oh!

jcscottiii commented Apr 7, 2026

Uh oh!

gsnedders Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

mstensho Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mstensho commented Jan 8, 2026 •

edited

Loading

jcscottiii Jan 20, 2026 •

edited

Loading