LGTM1, this has been thoroughly discussed in the CSSWG and the Mozilla
standards position issue and I think no more feedback is coming.

It's unfortunate that the testing infra is stuck in review, but at this
point I agree with not waiting. When the RFC is approved it would obviously
be nice to move the tests into WPT at that point.

On Wed, Apr 29, 2026 at 11:44 AM Morten Stenshorne <[email protected]>
wrote:

> *Contact emails*
> [email protected]
>
> *Explainer*
> https://github.com/mstensho/unprintable-areas
>
> *Specification*
> https://drafts.csswg.org/css-page-3/#page-margin-safety
>
> *Summary*
> Printers usually have a small area at each of the four edges of a sheet of
> paper that they are not capable of marking reliably, usually due to the
> printer’s paper handling mechanism. The default page margins are expected
> to be bigger than these areas, but if authors set margins on their own, and
> even want to add @page margin boxes (e.g. for custom headers and footers),
> they need a way of telling where it's safe to print and not. The CSS
> descriptor `page-margin-safety` can be used to steer clear of such
> unprintable areas.
>
> *Blink component*
> Blink>Layout>Printing
> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELayout%3EPrinting%22>
>
> *Web Feature ID*
> Missing feature
>
> *Motivation*
> The browser itself has access to information about unprintable areas, so
> that it can place UA-generated headers and footers within the printable
> area, and also make the default page margins large enough to prevent loss
> of content. But once authors want to set their own page margins, or add
> page margin boxes (for e.g. custom headers and footers), the problem
> becomes clear, since this information isn't accessible via CSS. When
> developers want to place content near the paper sheet edges, be it due to
> small @page margins or page margin boxes (for custom headers and footers,
> for instance), without this change, the author would either have to hope
> for the best, or add some "reasonably large" margin to steer clear of
> potentially unprintable regions on the sheet.
>
> *Initial public proposal*
> https://github.com/w3c/csswg-drafts/issues/11395
>
> *TAG review*
> https://github.com/w3ctag/design-reviews/issues/1115
>
> *TAG review status*
> Issues addressed
>
> *Goals for experimentation*
> None
>
> *Risks*
>
>
> *Interoperability and Compatibility*
> *No information provided*
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/1258)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/519)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> *WebView application risks*
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
> *No information provided*
>
>
> *Debuggability*
> *No information provided*
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?*
> Yes
>
> *Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
> No
> Proposal here, filed some months ago:
> https://github.com/web-platform-tests/rfcs/pull/233 Still in review, but
> feedback is generally positive. It's about a `<meta
> name="safe-printable-inset" content="[inset-specifier]">` to be specified
> in WPT print tests. `inset-specifier` is a numeric value in centimeters,
> which is the largest unprintable inset among the four edges of the paper
> sheet. This is already implemented in Chromium's content_shell WPT
> testrunner, and a few tentative tests have been upstreamed. All pagination
> tests are handled by this testrunner in Chromium, since the headless Chrome
> testrunner doesn't handle pagination reliably.
>
> *Flag name on about://flags*
> *No information provided*
>
> *Finch feature name*
> CSSSafePrintableInset
>
> *Rollout plan*
> Will ship enabled for all users
>
> *Requires code in //chrome?*
> False
>
> *Tracking bug*
> https://issues.chromium.org/issues/368070327
>
> *Estimated milestones*
> Shipping on desktop 150
> Shipping on Android 150
> Shipping on WebView 150
>
> *Anticipated spec changes*
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> *No information provided*
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5515971464527872?gate=6542696784855040
>
> *Links to previous Intent discussions*
> Intent to Prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKWZFm6j2Zg0UC78mnzF%2BRzeycQXzTPU_YpEZtAYAYQWNvgR8A%40mail.gmail.com
>
>
> This intent message was generated by Chrome Platform Status
> <https://chromestatus.com/>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKWZFm44zWMDWKRNKorGq%2BCjg4co%2BbGsZq%3DQYu-T9AhAnhtG-A%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKWZFm44zWMDWKRNKorGq%2BCjg4co%2BbGsZq%3DQYu-T9AhAnhtG-A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcR2X5Jduvn%3DRCmqRq0tqL6xyRYYuiNCBL0r6qfLmhgDg%40mail.gmail.com.

Reply via email to