Intent to Prototype: @page margin boxes
Morten Stenshorne
Contact emails
mste...@chromium.orgExplainer
https://github.com/mstensho/page-margin-boxesSpecification
https://drafts.csswg.org/css-page-3/#margin-boxesSummary
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>PrintingMotivation
Without this feature, authors have no means of providing their own headers, footers, or, say, a logo in one corner of every page, when printing, if the built-in CSS layout engine of the browser is to be used. The author would need to take full control and responsibility of the page layout on their own, by e.g. setting zero margins on every page, and manually create headers and footers near the edges, and manually lay out the actual contents of the document into e.g. one canvas per page, and perform all the layout on their own via some sort of advanced javascript layout library. Adding support for @page margin boxes solves this, by letting the author specify what to place into the various portions of the page area, and let the brower's layout and pagination engine do the job.
Initial public proposal
NoneTAG review
NoneTAG review status
PendingRisks
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.
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
Is this feature fully tested by web-platform-tests?
NoWPT tests will be written and submitted while working on this feature.
Flag name on chrome://flags
NoneFinch feature name
NoneNon-finch justification
NoneRequires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=320370Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5195769732923392
Philip Jägenstedt
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKWZFm6%3DPoqNsgRuKG0evLN8GAgWYhnyHzgv4Ru-F8%3DHjOcWsA%40mail.gmail.com.