LGTM2 On Mon, Sep 23, 2024 at 8:01 AM Mike Taylor <miketa...@chromium.org> wrote:
> 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 > . > -- 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/CAOMQ%2Bw8UsROUMmf3J%3DqWuWoYQhLKSXimipxhz_uWVHJOgXU6tQ%40mail.gmail.com.
