[css-lists] The implicit list-item counter

[FremyCompany]

It looks like both IE/Edge and Chrome/Safari use a counter named "list-item" to keep track of the current counter. Unfortunately, there is no interop on which value the counter has (I think Edge returns the correct value here).

https://wptest.center/#/kjrgz9

Is there any desire to standardize that, or should we just keep this an undocumented feature? ============> cc @kojiishi @dbaron

[fantasai]

https://www.w3.org/TR/css-lists-3/#declaring-a-list-item

[fantasai]

There is a spec for this list-item counter existing... the spec is still in the Exploring stage, so fairly shaky ground, but it does exist and was the result of WG discussions in the past, see e.g. message about implicit counter increments, related css-page-3 issue, WG agreement to keep the list-item counter in the spec. Do you have something specific that you want it to say or not say? :)

[FremyCompany]

I don't like how these counters work in Chrome, it's not useful. I also have the impression from glancing at the spec that Chrome is probably spec-compliant however, though today is definitely not the day I'll shine by my spec reading skills (evidence provided in post number one).

Could we change the spec so we get Edge behavior where using the counter provides you with the correct value? Or does the spec already make Edge's behavior correct and Chrome is off by one?

[FremyCompany]

Yeah, Chrome behavior is definitely weird. Maybe I should file a bug on them.
https://wptest.center/#/d4ie95

[fantasai]

@FremyCompany Spec for this is currently here https://drafts.csswg.org/css-lists-3/#list-item-counter Is there anything there you think needs to be fixed or expanded on?

[FremyCompany]

@fantasai I think Chrome behavior in this test case is incorrect, and it's probably a bug of Chrome not a bug of the spec; I don't think the spec needs changes. Maybe someone more familiar than me should take a look at the spec, and verify if the 1. A2 is somehow expected (I would think it is not, and 1. A1 is expected)

[fantasai]

@FremyCompany ... The testcase just has the one CSS rule? Yeah, I can't see any reason why it should be 1. A2.

[fantasai]

Looks like it's filed as https://bugs.chromium.org/p/chromium/issues/detail?id=796961 Flagging for WPT, remove tag if the testcase is actually checked in already. :)

[tabatkins]

I don't understand how Chrome's behavior is spec-compliant; I don't see any way to set up counter-increments that would lead to the first item's ::marker getting "1" but its ::after getting "2". Definitely looks like a bug.

I'm not looking at source code, but playing with the example it seems fairly clear that what's happening is the ::marker is still getting its counter value via magic, and the ol is defaulting to setting up an unrelated list-item counter with an erroneous counter-reset: list-item 1; declaration. (Check ol::before{content:counter(list-item);}; it returns "1".) This is a common mistake when someone isn't super familiar with the counter model; the first increment will apply before the counter is displayed, so you have to set up the counter-reset value accordingly.

@FremyCompany, did you ever file a bug? If not, I can file one.

[tabatkins]

Whoops, this tab had been open for a while, so I didn't see the more recent comments. All cool then, never mind @FremyCompany