Re: [csswg-drafts] [css-page] Should we allow resetting the `pages` counter? (#12824)

I think it is a good thing to have a predefined counter for the total number of pages that cannot be altered by authors. 

Since its static value can only be known after the whole document has been layed out, it is “expensive”. An author-defined counter could not provide the same result, since they are basically limited to the “current” value. 

As counter values are neither available for mathematical expressions inside `calc()` etc. nor as the `<integer>` within `counter-increment` etc., authors cannot calculate a derivative sub-total in another counter or custom property either. 

However, authors probably could generate arbitrary totals with the [`target-counter()` function](https://drafts.csswg.org/css-content-3/#target-counter) pointing to an ID at the end of the document – if that was implemented anywhere/ever.

This being said, I believe the better question to ask is:  
Which **other document totals** do authors want being available **as predefined counters** besides `pages`?

Introducing one for the total of non-empty pages might solve the use case presented here. 

Alas, I imagine the counts of all kinds of layout containers created by CSS – e.g. columns, boxes, cells, (grid) items, maybe even lines – could be of interest for generated content to someone. Most of those would need to distinguish a total for the whole document from one for the local context (i.e. a parent container like a grid or table). As counters with their limited applicability (compared to numeric `sibling-count()` etc.), the side effects could actually be manageable. 

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


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

Received on Thursday, 18 September 2025 11:31:34 UTC