- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Oct 2021 12:01:45 +0000
- To: public-css-archive@w3.org
We want to ship `reversed()` counter support in Gecko, so we'd like a resolution on this. Question 1: should a zero-valued `counter-increment` affect the automatic start value of reversed lists? I feel rather strongly that they should **not** affect the start value, for the following 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 (it's a feature and it also avoids `<summary>` unintentionally affecting the start value) 3. it preserves the invariant that a `counter-increment` with a zero value is idempotent w.r.t. the counter value, which enables possible implementation optimizations Question 2: as @Loirooriol suggested above (Option 2), using the value of the last `counter-increment` might be preferable over what the spec currently says, which is to use the value of the first `counter-increment`. (Given that the current spec text is fairly new (June #6233) I'm pretty sure no one have implemented/shipped that yet.) So, to be clear, the options for question 2 are: A. keep the spec as is: the first `counter-increment` value determines the counter value at the end B. change the spec to count the last `counter-increment` value twice instead, so that the last `counter-increment` value determines the counter value at the end I don't have a strong opinion on Question 2, but I think his suggestion makes sense so I'm slightly in favor of changing the spec to that. -- GitHub Notification of comment by MatsPalmgren Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6738#issuecomment-952852120 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 October 2021 12:01:50 UTC