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

MatsPalmgren has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-lists] automatic start value of reversed list is affected by 'counter-increment: <counter> 0' nodes ==
I just implemented the algorithm for instantiating `reversed()` counters described in:
https://drafts.csswg.org/css-lists/#instantiating-counters

I like how we now get symmetrical numbering, for example:
```html
<style>
li { counter-increment: list-item 2; }
[reversed] > li { counter-increment: list-item -2; }
</style>

<ol>
<li>a</li>
<li>b</li>
<li>c</li>
</ol>

<ol reversed>
<li>a</li>
<li>b</li>
<li>c</li>
</ol>
```

now results in `2, 4, 6` followed by `6, 4, 2`.  But, I also note that the `reversed` result isn't backwards compatible: both Firefox and Chrome currently shows `2, 0, -2`.  However, I'm willing to try to ship it if other UAs agree with that...

Anyway, this issue is about this case:

```html
<ol reversed>
<div><details><summary>x</summary></details></div>
<li>a</li>
<li>b</li>
<li>c</li>
</ol>
```

This example does **not** result in the same numbering as the first `reversed` case above, and is asymmetrical with the non-`reversed` case with the same content.

The problem is that `<summary>` has a `counter-increment: list-item 0` (`display: list-item` would otherwise create a non-zero increment):
https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements

That affects step 3.2 in the algorithm: "If first is true, then add incrementNegated to num and set first to false.".

I think we should change this step to exclude `counter-increment` values that are zero, so the step would begin:
"If first is true and incrementNegated is non-zero, then ..."

(Arguably, the bug is that `<summary>` shouldn't have `display: list-item` to begin with. It's just a gross hack to display its disclosure arrow... Hopefully we can fix that at some point by making it `display: block`, remove its `counter-increment`, and generalize `::marker` pseudos to apply to all `display` values in some way, but that's a bigger change that I don't want to tackle right now to fix this minor issue...)

I would argue this is a good change for three reasons:
1. a `counter-increment` declaration with a zero value indicates an intent from the author that this element shouldn't affect the counter numbering
2. it seems more practical/useful if it doesn't affect the counter start value
3. it preserves the fact that `counter-increment` with a zero value is idempotent w.r.t. the counter value, which enables possible implementation optimizations

(Discussion that lead up to the algorithm in question is in #6233.)

CC @zcorpan @tabatkins @emilio @Loirooriol 




Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6738 using your GitHub account


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

Received on Monday, 18 October 2021 00:42:46 UTC