LGTM3
/Daniel
On 2024-09-23 17:08, Chris Harrelson wrote:
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 <http://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
<mailto:blink-dev%2bunsubscr...@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
<mailto:blink-dev%2bunsubscr...@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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8UsROUMmf3J%3DqWuWoYQhLKSXimipxhz_uWVHJOgXU6tQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/89c92ebe-e721-4270-adc9-959eb90804ee%40gmail.com.
