- 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