- From: Mike Bremford via GitHub <noreply@w3.org>
- Date: Thu, 18 Sep 2025 14:42:19 +0000
- To: public-css-archive@w3.org
> 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 is fairly widely implemented I believe, and I agree it is a suitable replacement for this requirement although it's slightly awkward - it requires something like `<div style="height:0" id="lastitem"></div>` at the end of the body. On this proposal: * I am worried that`counter-reset` creates a scope; we really don't want to do that for pages. * I can see your argument for `counter-set` - your use case seems a good one. * It could get really confusing if `counter-increment` was set to a value other than 1, although there might be some special reason for it. And if you allow `counter-set` there is no technical reason to allow `counter-increment` as they work the same way. * I presume this is still a single counter with a single value? So if `pages` was reset halfway through the document, for example, the value for `pages` is the same on every page in the document, as it is now. If it stayed as single counter and was limited to `counter-set` and possibly `counter-increment` I think we'd be OK with this. Re the comment from @crissov, I don't think there's a need for more "special" counters identified by special names like `pages`. There's certainly more we could do with counters, but defining new magic ones isn't something we could do without potentially breaking existing use of those names. -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12824#issuecomment-3307874840 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 14:42:20 UTC