[css-lists-4][css-content-3] Add counter-style property to associate default counter style

[fantasai]

Currently counters are associated with a name, but they're not associated with a counter style. You have to provide that style manually every time you use the counters() function. This is kindof okay for most uses of counters, but it's a bit of a problem for target-counter() because then you have to track which counters use which styles, and it gets extra complicated if you want to do multi-level lists (which all have the same counter name).

I think it would be good to introduce a counter-style property that tracks with counter-reset, and associates the named counter with its default style. Authors can still override it, but then at least it can default to the same representation everywhere it occurs.

[tabatkins]

counters() is even more problematic tbh; you simply can't use it if the distinct levels use different counter styles, since it maps all the counter values into the specified style.

So I agree that lettings counters have an associated style which is used by default would be pretty nice.

[faceless2]

Thank you @fantasai for bringing up target-counter. This case has always bugged me - my chapters are styled in upper-roman, but if I use target-counter(attr(href url), chapter) I get decimal, and I've no way of saying "give me the style used by the target". So I thoroughly support this.

One worry I have with counter-style is the additive CSS issue - presuming a syntax like counter-style: chapter upper-roman, I can set the style for a particular counter but only by resetting all other styles. I know it's not a new issue or specific to this property, and I appreciate it's a tricky one.

[fantasai]

@faceless2 I was intending that you only affect the counters reset in counter-reset on the same element.

[css-meeting-bot]

The CSS Working Group just discussed [css-lists-4][css-content-3] Add counter-style property to associate default counter style, and agreed to the following:

• RESOLVED: add counter-style that associates default counter styles with each counter specified by counter-reset on the same element
• RESOLVED: counter-style property takes a list of counter style keywords, which are matched up to counter-reset using coordinated list logic
• RESOLVED: name tbd
• RESOLVED: Work on counter shorthand
• RESOLVED: All the counter things

The full IRC log of that discussion

<emilio> fantasai: when you define a counter there's no association with counter style, just number+scope
<emilio> ... for anything other than decimal you need to explicitly set it every time you use counter() functions
<emilio> ... that's a minor difficulty and it gets even worse with target-counter()
<emilio> ... when you want to do multi-level lists you can't use different styles
<emilio> ... proposal is a counter-style list, much like counter-reset
<emilio> ... that associate counters with a default style
<Rossen_> q?
<emilio> ... I think it's a reasonable way of solving the issue
<emilio> q+
<bramus> emilio: would target counter take the counter from the elemen tyou are styling or the target element?
<bramus> fantasai: from the style associated with the counter
<Rossen_> q?
<emilio> fantasai: if you use implied counters but don't use counter-reset then you can't associate a style
<bramus> emilio: seems fine
<ntim> q+
<oriol> q+
<emilio> fantasai: it only works when you specify counter-reset
<emilio> ack emilio
<Rossen_> ack ntim
<emilio> ntim: how does this interact with the second argument to counter()?
<emilio> TabAtkins: that wins. Right now if you don't specify a second argument you get decimal, we'd change that
<Rossen_> ack oriol
<emilio> oriol: You mention this could be like counter-reset list, which doesn't use commas and has been a problem
<emilio> TabAtkins:
<emilio> TabAtkins: +1 for commas
<emilio> fantasai: I'd prefer to use commas
<emilio> ... if we used commas everywhere else
<emilio> ... so I'd be ok with adding a shorthand or something that uses commas
<emilio> ... but it'd be weird to make this the only counter prop that doesn't
<Rossen_> q?
<emilio> fantasai: proposal is add counter-style that associates default counter styles with each counter specified by counter-reset on the same element
<TabAtkins> i mean i guess we could define you could use, like, `[]` around your value to do more than the specified things
<TabAtkins> anyway this is on my time-travel list
<emilio> RESOLVED: add counter-style that associates default counter styles with each counter specified by counter-reset on the same element
<TabAtkins> 1) kill hitler, 2) introduce utf-8 five years earlier so ucs-2 never gets created, 3) put commas in the counter-* properties
<SebastianZ> +1 on that. ;)
<emilio> fantasai: follow-up question: there are two ways of binding styles with the names
<emilio> ... right now counter-reset gets name and value
<emilio> ... we should counter-style either just get the values and use the positional matching
<emilio> ... or follow the same syntax as counter-reset
<emilio> q+
<emilio> ... and specify the name
<bramus> emilio: i think i have slight preference to use the positional one, otherwise it would feel like ???. my understanding is that it wouldnt
<bramus> … feels more confusing with the ?? and is slightly more inefficient
<dbaron> s/???/it would work without using counter-reset/
<bramus> … but that last thing is a minor thing
<TabAtkins> i should come up with a `counter` shorthand
<oriol> q+
<emilio> ack emilio
<TabAtkins> but +1 to emilio, don't have a strong opinion and that sounds fine
<Rossen_> ack emilio
<Rossen_> ack oriol
<emilio> oriol: I think we have the typical problem of what happens when you specify a list that's longers
<emilio> fantasai: we do the same as for background and animations etc
<emilio> ... so if you use counter-style: alphabetic and two counter resets then both are alphabetic
<bramus> emilio: so the shorter this behavior i think at some opoint some browsers clmaped the bg list and that is not great. it computes as a specified and then uses ???.
<bramus> fantasai: we should use the same rules
<Rossen_> ack dbaron
<emilio> dbaron: I think I agree with the conclusion about using the styles without the names and the list matching
<emilio> ... the issue I find with that solution is the name of the property
<emilio> ... counter-style doesn't feel like something that's talking about counters you are resetting
<emilio> fantasai: not concerned about it because we already have list-style and counter()
<oriol> q+
<emilio> dbaron: I think people are going to try using it on the element that's using the counter and get confused
<Rossen_> ack oriol
<emilio> oriol: Why are we tying this to counter-reset? Could we provide a way of specifying the associations separately?
<emilio> fantasai: you need to do it when the counter is created and counter-reset is what does that
<ntim> q+
<emilio> ... so it has to be tracked with the property that instantiate the counter
<emilio> q+
<emilio> ... counter-increment/set create implicit resets
<emilio> oriol: couldn't you provide a way to change the style separately from the counter
<emilio> fantasai: maybe I don't think that's useful?
<emilio> ... then we'd need to define the scoping etc
<emilio> oriol: other properties are not tied to reset
<emilio> fantasai: right because they change the value of the counter
<Rossen_> ack ntim
<emilio> ntim: Can we make this new property inherited?
<emilio> fantasai: no
<emilio> ... that doesn't give you good result
<emilio> TabAtkins: won't pair well, it also prevents shorthandifying counter styles
<emilio> fantasai: inheriting would cause wrong results if you only specify counter-reset somewhere down the tree
<emilio> q+
<Rossen_> q?
<Rossen_> ack emilio
<bramus> emilio: my other q is can we extend the counter-reset synbtax to allow this?
<bramus> TabAtkins: no, unless we want it to take a function
<miriam> q+
<bramus> … which can be space separted. but bc lack of commas we cant
<ntim> q+
<bramus> emilio: counter-reset takes item number/
<bramus> TabAtkins: ident optional number
<bramus> emilio: I guess you could maybe put the style with brackets but that sucks?
<bramus> TabAtkins: that is essentially a function
<bramus> … we should define a counter shorthand
<bramus> … and it will have commas
<ntim> q-
<bramus> fantasai: yes
<bramus> TabAtkins: we screwed up the counter-* props initially. dont knwo why
<emilio> dbaron: I think counter props might be the first list valued prop
<emilio> fantasai: font-family!
<emilio> miriam: I'm not totally convinced by arguments against tim's proposal
<emilio> ... I might want to to set the counters for the whole site
<Rossen_> ack miriam
<ntim> q+
<emilio> fantasai: then set it on * but otherwise inheriting gives you weird behavior for all the decimal-based counters that already work
<Rossen_> ack ntim
<emilio> ntim: my rationale was more something like list-style where you put list-style on the list-container
<emilio> TabAtkins: that's fair but list props are all inherited
<emilio> ... we're keeping those as consistent as possible
<bramus> emilio: you usually counter rest on the list container. so that would still work
<emilio> s/rest/reset
<emilio> fantasai: proposed resolution is a counter-style prop that takes a list of names
<bramus> emilio: regarding the name; counter-reset-style maybe?
<emilio> TabAtkins: fine with something like that
<emilio> ntim: can we resolve on working on the shorthand?
<emilio> TabAtkins: I'd be happy to resolve on that
<fantasai> PROPOSED: counter-style property takes a list of counter style keywords, which are matched up to counter-reset using coordinated list logic
<emilio> proposed: Add a property (counter-style/counter-reset-style/exact name tbd) that takes a list of counter-style names and gets associated to counter-reset using the coordinated property list behavior
<fantasai> RESOLVED: counter-style property takes a list of counter style keywords, which are matched up to counter-reset using coordinated list logic
<TabAtkins> RESOLVED: name tbd
<emilio> RESOLVED: Work on counter shorthand
<astearns> RESOLVED: All the counter things