Re: [csswg-drafts] [css-gcpm-3] string-set with counter(page), when is value resolved? (#4740)

Without resolving this issue, the behaviour of a string set to _any_ counter incremented in the page margin is quite different to a string set to anything else. Prince only allows one counter in the page margin, `page`, which might be why I'm struggling to convey the issue if that's the one you're testing against. But others might include:

1. Keeping track of the physical number of pages, as Antenna House does with their "page physical" counter.
2. Displaying the number of pages in a page group, or a chapter, or appendix.


Let me try again with a self-contained, complete example. Would be great to get your results from PDFReactor, and AH Formatter if you ever find it :-)

```html
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <style>
  :root {
     counter-reset: page 0 b 0;
  }
  @page {
     counter-increment: page 1 b 1;
     @top-center {
         content: counter(page) counter(b) string(c) string(d);
     }
  }
  div {
      break-before: page;
  }
  #div1 {
      string-set: c counter(page), d counter(b);
  }
  </style>
 </head>
 <body>
  <div id="div1">Div1</div>
  <div id="div2">Div2</div>
  <div id="div3">Div3</div>
 </body>
</html>
```

What I expect to see here is that `counter(page)` and `counter(b)` increment on each page, but the two strings are set to the value "1" on the first page and remain at that value. So we should have page1=1111, page2=2211, page3=3311 (the final two values could also be "0", that's a separate issue with counter scope I'm about to file against css-page. But the point is, they don't change).

The results I've tested here are:

* Weasyprint: page1=1100, page2=2200, page3=3300
* Prince: page1=1010, page2=2020, page3=3030
* Our unreleased renderer: page1=1111, page2=2211, page3=3311
* PDFReactor: not tested
* Antenna House: not tested


Prince doesn't handle any page-margin counters other than "page", which is why "b" is never incremented. Because the `page` counter is magic, they can easily extend that magic to any string set to the value of `counter(page)` and have it always reflect the current page number.

But once you open the door to counters other than `page` being incremented in page margins it gets much harder. If "page" type counters are handled differently to other counters, you have to keep track of which is which. And if you increment a counter in _both_ contexts - odd, but perfectly valid - you're stuck (I have a pile of tests for this topic, but the good news is they're all against css-page, so you're off the hook for those ones).

I've expended a lot of words on this topic, sorry. My fundamental point is that "the page counter is not magic".  We _have_ to be able to explain the behaviour of `string: x counter(page)` without treating "page" differently to any other counter.

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

Received on Thursday, 27 February 2020 17:39:29 UTC