Re: [csswg-drafts] [css-values] enable the use of counter() inside calc() (#1026)

I like this in general and I'd love to see it implemented too. But I'd really, really hate implementing it.

All of the paged media layout engines have the same problem with counters, in particular "page" and "pages", although technically it's any counters incremented in the @page margin areas (still a largely theoretical constraint at the time of writing). The moment you hit one of these you have to consider a second layout pass - it's not always required, but for something like `span::after { content: counter(pages upper-roman); }` you really haven't got much choice.

You need the first layout pass to count the pages, or to work out with certainty which page your element is on (that's more of an issue with `target-counter(nnn, page)` to be fair). But once you start introducing counters to other properties - say `margin-top: calc(counter(pages) * 20px)` - you've introduced a loop: layout depends on values computed from an earlier pass of the layout, and so on.

It's not quite as awful for the "page" counter, or any counter other than "pages". But it's still a little complex: `orphans: calc(counter(page) * 20)` may force a page-break, which would change the value of orphans...

So although I'm not exactly against this, I just wanted to flag that it is almost unfeasibly hairy for some cases. Think  of the multiple passes required to stabilise layout for ::first-line, except it's a _whole document_ that needs to be stabilised. These would need to be considered if this goes anywhere.



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


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

Received on Wednesday, 5 August 2020 19:13:05 UTC