safe-printable-inset META value proposal #233
There are no files selected for viewing
| 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. | ||
|
|
||
| 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
Member
There was a problem hiding this comment. This does leave us unable to test all the different at-rules the descriptor applies to — The spec says, along these lines:
It's not entirely clear to me from the spec how you go from potentially seventeen values (if specified in 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
Author
There was a problem hiding this comment. 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.
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 |
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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:reftest-wait.There was a problem hiding this comment.
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?