Repository navigation
[css-lists-3] counter-set vs counter-increment #3810
Description
Re: Counter properties in CSS Lists Editor's Draft
There's some ergonomc awkwardness about counter-set vs counter-increment, e.g. in #3686 it's pointed out that you'd have to zero out the list-item increment when setting the counter for <li value=...>. (This particular case is technically problematic as well as unweildy because it'd get wiped out by an author counter-increment declaration; but there's some awkwardness either way and it doesn't cascade well for anyone.)
I'm wondering if instead of applying counter-reset, then counter-set, then counter-increment, we should apply counter-reset, then counter-increment, then counter-set? Then when you “set” a counter on an element, you actually get that value back, which seems a little more intuitive (and also solves the list-item problem).
Activity
fantasai commentedon Apr 6, 2019
It also gives better cascading behavior in general (not just for the author/ua list-item negotiation).
AmeliaBR commentedon Apr 6, 2019
Does
counter-sethave any implementations? That could create compat issues.If there's no compatibility objections, I agree that it is preferable if
counter-setoverrides any increments. If I specifycounter-set: chapter 5, that's probably what I want.The downside is that
counter-reset: chapter 5would work differently; an increment declared on the same element would add to the initial value. But that's less likely to be a problem oncecounter-setis supported;counter-resetcan be used as intended, on the parent element that defines the counter scope.emilio commentedon Apr 6, 2019
There's Gecko's implementation, but that's not on release yet so we can change that without much hassle I'd guess.
But I'd rather get a speedy resolution than doing it once it's hit release.
cc @MatsPalmgren in case he has objections.
MatsPalmgren commentedon Apr 7, 2019
I like this proposal. It makes
counter-setsimpler to use for authors and implementors alike. In particular, we can now map<li value=N>to justcounter-set: list-item Nmaking it independent of anycounter-incrementthe author might have on that element (as @heycam noted as a problem in #3686 (comment)).(I'm fixing Gecko here.)
css-meeting-bot commentedon Apr 10, 2019
The CSS Working Group just discussed
apply counter-set after counter-increment, and agreed to the following:RESOLVED: apply counter-set after counter-incrementThe full IRC log of that discussion
<dael> Topic:apply counter-set after counter-increment<dael> github: https://github.com//issues/3810
<dael> fantasai: This was an issue around interaction. Property values you have to set if you're incremeneting on every item and want to set to a particular value. yOu have to set it minus increment. That's ergonomically awk
<fremy> (I'm in favor)
<dael> fantasai: Suggestion is set counter set after increment so if you set foo 5 it will be 5 no matter the counter increment
<dael> fantasai: Generally better cascading behavior. Counterset wins over counter incrememnt rather than adding to it.
<dael> gregwhitworth: When you set counterset it starts from that place?
<dael> fantasai: Sets an explicit value for the counter
<dael> gregwhitworth: And doesn't inc after that?
<dael> fantasai: If you have nth-child 5 counterset: chapter 5 it will have 5 instead of the increment added to that.
<dael> gregwhitworth: Then increment from 5?
<dael> fantasai: On other elements, yeah.
<dael> fantasai: On a particular element you apply counter-reset then counter increment then counter set
<dael> plinss: Makes sense to me. Looking at issue Gecko impl but will change. Any other impl here?
<dael> fantasai: I think they're only ones. They committed the fix a day ago
<dael> plinss: Objections?
<dael> RESOLVED: apply counter-set after counter-increment
[css-lists-3] Apply counter-set after counter-increment (overriding t…