Thanks for the clarifications.

LGTM1

On 9/23/24 12:00 AM, Morten Stenshorne wrote:
Mike Taylor <miketa...@chromium.org> writes:

On 9/19/24 4:58 PM, Chromestatus wrote:

  Contact emails

  msten...@chromium.org

  Explainer

  https://github.com/mstensho/page-margin-boxes

  Specification

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

  Summary

  Add support for page margin boxes, when printing a web document, or exporting 
it as PDF. @page margin boxes
  allows an author to define the contents in the margin area of a page, for 
instance to provide custom headers and
  footers, rather than using the built-in headers and footers generated by the 
browser. A margin box is defined via an
  at-rule inside a CSS @page rule. There are 16 rules defined, one for each 
page margin box. There's one margin box
  for each of the 4 corners on the page, and three (start, middle, end) for 
each of the 4 sides. The appearance and the
  contents of a margin box are specified with CSS properties inside the at-rule, 
including the "content" property.
  Counters are also to be supported, for page numbering. The specification 
defines two special counter names:
  "page" for the current page number, and "pages" for the total number of pages.

  Blink component

  Blink>Layout>Printing

  TAG review

  https://github.com/w3ctag/design-reviews/issues/918

  TAG review status

  Issues addressed

  Risks

  Interoperability and Compatibility

  The spec defines the CSS counter names 'page' and 'pages'. Both are 
accessible by the document's contents, so
  that any element may use the counters to tell the current page number, or the 
total number of pages. Documents
  that use these counter names without being aware of this feature may be in 
for a surprise. Most browsers offer to
  generate some default headers and footers, and they are usually enabled by 
default. If the document has margin
  at-rules, they may come in conflict. We need some way of making sure that we 
either use the browser-default
  headers and footers, or the author-defined @page margins.

Can you clarify what you mean by "in for a surprise"?

I don't think I understand the compat implications of @page+
margin boxes here.
I'll remove this at chromestatus. It is no concern for now, since
counters in page / margin contexts will not interact with those of the
document. I.e. it's something we don't implement yet. The spec suggests
that they should interact, but it is vague, not too well thought through
(the spec forgets about parallel flows, for one), and the whole thing is
kind of weird, as counters are resolved in DOM tree order (i.e. the
precense of out-of-flow box, floats, etc.) do not affect the counter
scopes / values. Page / margin counters, on the other hand, need to be
resolved during layout. So we can revisit this later.

I wrote about this here (but how to fix the spec hasn't been discussed
yet):
https://github.com/w3c/csswg-drafts/issues/4760#issuecomment-1959298806

Also, do you have a plan for default header/footer conflicts w/ 
developer-provided ones?
Yes, sorry, forgot to update chromestatus again. Now fixed.

Most browsers offer to generate some default headers and footers, and
they are usually enabled by default. If the document has margin
at-rules, they may come in conflict and overlap if no action is
taken. Our solution: When a page has author-defined @page margin boxes
at the same edge of the page as a browser-default header or footer, the
browser-default ones will be suppressed (not displayed). This is in a
way similar to how the browser-default headers and footers are
suppressed when @page margins become too small for them to fit there
(with @page margin boxes, the author kind of takes control of the margin
area, and therefore there's nothing left for the UA, as if the margin on
that edge is zero).

  Gecko: No signal (https://github.com/mozilla/standards-positions/issues/921)

  WebKit: No signal (https://github.com/WebKit/standards-positions/issues/275)

  Web developers: Positive 
https://bugs.chromium.org/p/chromium/issues/detail?id=320370 currently has 98 
stars.

  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?

  None

  Debuggability

  None

I think it's possible to emulate the print media via DevTools. Maybe there are 
other possible debug modes to visually
represent these named margin boxes (as follow up work)?
Yes, we can emulate print media, as in "match @media print rules". But
that doesn't give us pagination. Getting devtools to paginate, so that
one could inspect the page boxes and margins (and margin box contents)
could indeed be useful. This is something that would have been useful
for years already, but with richer pagination support (like @page margin
boxes) it does become even more interesting.

There's crbug.com/40728089 for this.

  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?

  No

  WPT tests will be written and submitted while working on this feature.

  Flag name on chrome://flags

  None

  Finch feature name

  PageMarginBoxes

  Requires code in //chrome?

  False

  Tracking bug

  https://bugs.chromium.org/p/chromium/issues/detail?id=320370

  Estimated milestones

   Shipping on desktop  131
   Shipping on Android  131
   Shipping on WebView  131

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

  None

  Link to entry on the Chrome Platform Status

  https://chromestatus.com/feature/5195769732923392?gate=6322213557108736

  Links to previous Intent discussions

  Intent to Prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/ZCPkcu_dSF8

  This intent message was generated by Chrome Platform Status.
  --
  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
  blink-dev+unsubscr...@chromium.org.
  To view this discussion on the web visit
  
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66ec9090.2b0a0220.b3b1b.006b.GAE%40google.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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dff2c291-19d5-452a-a71e-3f4f0a35c1d4%40chromium.org.

Reply via email to