Re: [csswg-drafts] [css-lists] automatic start value of reversed list is affected by 'counter-increment: <counter> 0' nodes (#6738)

>  Here's the most recent example we encountered - it's a large legal document with many thousands of <summary> elements which are all in the same (implied) counter scope. Excluding those from our internal CSS counter data structures is a significant performance optimization in Gecko (as I was alluding to in my point 3 above).

It would have been useful to lead with that, so we knew the "possible implementation optimizations" you allude to in the OP aren't theoretical but extremely real and immediately demonstrated! That changes the calculus a bit.

Okay, so, reversed counters are weird in the first place. In the trivial case, when all the increments are identical and there's no counter-set, we can get a reasonable result that looks symmetrical with a non-reversed counter. But in *any* non-trivial case we'll get a break in the symmetry: some intentional, like a counter-set causing the following items to count down from it (in the non-reversed case, the preceding items are causally disconnected from the counter-set value, instead); some unintentional, just because the order of value inheritance is always preceding->following, which breaks the symmetry.

If we just set all the non-trivial cases to the side, we could go with "use the first increment" and just deal with it. But we're already going to *some* effort to line things up in non-trivial cases (counting up the increments, stopping at the first counter-set, etc), and you already have to process an arbitrary number of elements in the general case to find the counter's starting value *anyway*, so we might as well do the more-likely-to-be-correct thing and use the final increment instead (or the final increment before a counter-set), pretending that there's a last+1 increment of the same size that finally reduces the counter to zero as it reaches the end of its scope.

While respecting a final increment of zero would be "more correct", I agree that a zero increment in this case can be safely ignored. Especially in this case, since it's *required* to avoid changing the `list-item` counter, since if you leave it off it auto-increments.

So yeah, let's go with:

* collect all increments from elements preceding the first counter-set (or all of them, if there's no set)
* pretend there's a last+1 increment of the same size as the last non-zero increment, which takes the counter to the counter-set value (or to 0)
* then reverse the increments back to the beginning to find the starting value

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


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

Received on Thursday, 28 October 2021 18:58:53 UTC