Re: [csswg-drafts] [css-page] Expose unprintable areas via CSS (#11395)

Your proposal in https://github.com/w3c/csswg-drafts/issues/11395#issuecomment-3574884260 seems great to me.

Regarding your example use-case for `add` in https://github.com/w3c/csswg-drafts/issues/11395#issuecomment-3574884260 with content in the top margins:

I agree with you about this being a reasonable use-case where an author might want `add` on one side vs. `clamp` or `none` on other sides -- so, I agree that maybe adding longhands per-side would be wise.  (However, I don't have a strong preference for whether we do that up-front or just leave open the option to do it in the future.)

I have one suggestion on this part of the suggested spec-text:
> page-margin-safety only affects margins that are adjacent to a page's edges. In other words, when page-margin-safety is specified in a margin context, it will only have an effect at one or two sides. 

**Suggestion:** For the purpose of making this easier to reason about and to spec, it's probably simplest to handle this by defining the `<safe-printable-inset>` as being `0` on **all sides of a page-margin-box that are adjacent to the `page box`** (i.e. all of the sides that are facing inward toward the document).  That lets us define the algorithm without having to consider which edges the property does/doesn't apply to; it just applies everywhere, but in some cases the safe-margin is 0 (which makes it irrelevant for those edges).

Also: I think we **need to be very careful** to define how `@page { page-margin-safety: [clamp|add] }` impacts the size & placement of the margin boxes -- specifically, we need to define what it means for the algorithm in https://drafts.csswg.org/css-page-3/#fixed-sizing (section 5.3.3).  We can perhaps leave the details to spec-editors - but I'll explain the edge cases I'm thinking about, as motivation for you and/or spec editors to make sure it's coherent.

In short, for the margin-box context: there's **already spec text on how to arrive at the used value of the `margin-*` descriptors** (in section 5.3.3), so we can't just add new spec test defining how to get their used value from a computed value.  It would conflict with this existing text, so we have to thread it in to make it coherently interact.
* The existing algorithm (in 5.3.3) is carefully written to make sure that the margin-box's geometry precisely fits (i.e. its margins, borders, padding, and height exactly fill the page-margin); so we can't take the easy way out and e.g. just handle margin-safety as something that happens **after** that algorithm.  If we did that, we'll potentially make the page-margin-box geometry too large, and we'd overshoot the available page-margin space.
* We have to think carefully about the situations in step 2 and 3 where the spec says to treat the margin-box's margins as if they were `0` or `auto` (in order to address situations with impossible constraints). We'll need to define whether margin-safety kicks in before or after that conversion to `0`/`auto` -- or really, whether it creates a different more-subtle form of fallback (e.g. maybe instead of falling back to `0`, we fall back to the `<safe-printable-inset>`, or as much of it as we're able to fit?)
* In step 5 (where we divide space equally among `auto` margins), we need to ensure that we can satisfy the `<safe-printable-inset>` (which may be larger than the "equal share", on the outwards-facing side at least).  And we need to figure out how to think about whether `add|clamp` should produce different outcomes in this step. (For example: maybe `add` reserves `<safe-printable-inset>` for each side first, and then divides the *remaining* space between the margins? Whereas `clamp` divides the space as equally as possible, subject to satisfying the `<safe-printable-inset>`.  In both of these cases, we need to figure out what happens if the remaining space is larger than the `<safe-printable-inset>`, too.)

-- 
GitHub Notification of comment by dholbert
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11395#issuecomment-3619023738 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 6 December 2025 00:20:06 UTC