Re: [csswg-drafts] [css-page-3] Page-based counters not working with forced breaks. (#4760)

I've been staring at the spec for quite some time now, and have come to realize that some care may have been taken there to prevent two-way interaction between page/margin contexts and the document (which seems to be what you're trying with the section counter example above). Because, regular CSS counters follow the document tree order, whereas pages are created during layout. This means that the document counter values have already been calculated when laying out the pages. Reading out counter values from the "deepest element in the normal flow that spans the page break" to use it in a page margin context should be fine, but writing anything back to the document counters at this point sounds messy, if there are parallel fragmentation flows, for instance.

Consider this example:

```html
<!DOCTYPE html>
<style>
  @page {
    @top-right {
      content: "telle " counter(telle);
    }
  }
  .increment {
    counter-increment: telle;
  }
  .show::before {
    content: counter(telle);
  }
</style>
<div class="increment show"> (expected 1)</div>
<div style="float:right; background:cyan;" class="increment show">
  (expected 2)
  <div style="break-before:page;" class="increment show"> (expected 3)</div>
  <div style="break-before:page;" class="increment show"> (expected 4)</div>
</div>
<div class="increment show"> (expected 5)</div>
<div style="break-before:page;" class="increment show"> (expected 6)</div>
<div style="break-before:page;" class="increment show"> (expected 7)</div>
```

What should the page numbers in ```@top-right``` be? 0 for the first page, 5 for the second page, 6 for the third page? That's the counter values from the normal flow at the break points, at least what I see in Chrome and Firefox. Supporting this seems unproblematic, but letting page / page margin contexts affect the counter values in the document would cause a mess.

Actually, for the other way around - using counters in the document that have been set in page / margin contexts, since regular counters are calculated in document tree order, whereas page counters are a function of layout, I think the pagination spec needs to be a bit more elaborate on how this is supposed to work. Since counters are resolved before layout (and pagination), I guess they somehow need to be re-resolved during layout, to be updated with the correct page number for counter(page), and so on?

And, I must ask: what's the usefulness in letting the elements in the document be affected by page and page margin contexts? I really understand the usefulness of the other way around, though (display chapter numbers in the header, or even more useful things with string-set and string()), but referencing stuff from margin boxes in an element in the document... why?

-- 
GitHub Notification of comment by mstensho
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4760#issuecomment-1959298806 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 22 February 2024 11:56:29 UTC