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. > -- Morten Stenshorne, Software developer, Blink/Layout, Google, Oslo, Norway -- 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/87o74e26s4.fsf%40bro.lan.
