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

For posterity if we ever loop back to this issue, thanks to https://printcss.live I can answer my own question in https://github.com/w3c/csswg-drafts/issues/4740#issuecomment-592085773

* AH7: 11x1, 22x2, 33x3 (where x is the error message "#c is not constructed#)
* PDFReactor: 1100, 2200, 3300
* Prince13:  1010, 2020, 3030
* Prince14: 0100, 1210, 2320
* Vivliostyle: 1100, 2200, 3300
* Weasyprint: 1100, 2200, 3300
* bfo: 1111, 2222, 3333

For my second example immediately above, for the products that give complete output:

* AH7: V1P1, V1P2
* PDFReactor: V1P1, V1P1
* Prince14: V1P1, V1P2
* Weasyprint: V2P1, V2P2
* bfo: V1P1, V2P2

Brief analysis:

* AH7 and bfo consider the `counter-reset` on :root to be _before_ the first page
* Prince14 does something with `counter-reset`, but I'm not sure sure what and it seems to be tied into the `page` counter being magic.
* PDFReactor, Weasyprint, Vivliostyle do not seem to share scope between body and page-margin counters, or if it is shared it's not as specified
* Prince14 and bfo can set a string to the `page` counter, AH7 and bfo can set a string to a non-`page` counter.
* Prince14 and AH7 treat the `page` counter differently than other counters - `page` is copied to strings by reference, others seem to be copied by value.







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


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

Received on Tuesday, 1 March 2022 16:20:22 UTC