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

> Another possibility would be changing the normal order and say that, for reversed lists, counter increments are applied after using the values.

Wouldn't that break child list numbering? Extending your first example:
```html
<style>::marker { content: counters(list-item,".") }</style>
<ol reversed><!-- 5 -->
  <li style="counter-increment: list-item -2"><!-- 5 --><ol><li>a</ol></li>
  <li style="counter-increment: list-item -3"><!-- 3 --><ol><li>b</ol></li>
</ol>
```

The child list items would show "3.1a" and "0.1b" respectively, no?

Anyway, I don't think invasive changes like that are acceptable to us.  Firefox have been shipping `<ol reversed>` and honoring `counter-increment/set/reset: list-item` values for years now.  The one and only case where I think we're open to breaking changes are reverse counters that doesn't have a start value. As I said in the OP, the result `2, 0, -2` doesn't really make much sense, so authors encountering that is likely to have shaken their head and added a start value to get the expected result.


So the options I see are:
1. let the first non-zero increment determine the start value (what I propose)
2. let the last non-zero increment determine the start value (your `vn + kn = 0` alternative, with the added condition that zero-valued increments are ignored)
3. set a start value that will make the last item have the value `1` (your `vn = 1` alternative)

The third option seems like it would lead to undesirable results in the common case.  The common case is that all the increments have the same value, e.g. `li { counter-increment: list-item -2; }` and I think it would be surprising if the list doesn't end with the value `2` in this case.  I think that's the intent behind the current algorithm in the spec.

So that leaves options 1 or 2.  I don't feel strongly either way, but I do feel rather strongly that zero-valued increments should be ignored, for the reasons I gave in the OP. I think option 2 would be slightly more complicated to implement - the current algorithm can be done as one pass over the counters, but I think option 2 would need a second pass. Option 2 also needs a way to gracefully deal with `counter-set` nodes, which option 1 handles quite nicely.

So, given that I don't see any obvious advantages from switching to option 2, I still think option 1 is the best one. (In the common case of all list items having the same increment, they will lead to the same result anyway.)


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


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

Received on Tuesday, 19 October 2021 06:43:06 UTC