[css-lists-3] Should automatic list-item increment adjust for ol[reversed]?

[fantasai]

The list-item counter is defined to automatically increment by one on each element with display: list-item. (See #3686 for how that works.) <ol reversed> lists need to have a list-item increment of -1.

Should this be done by magic interactions with the host language, or should the UA style sheet simply include ol[reversed] > li { counter-increment: list-item -1; }?

[tabatkins]

It doesn't work thru the UA stylesheet:

• That requires that it show up in the serialization of the computed value of 'counter-increment', which no browser does, and which Firefox tried to do but backed off from. (Well, I think they just tried to do the normal incrementing, but it seems weird for ol to influence counter-increment sometimes but not other times.)
• It means that any non-initial value for counter-increment needs to explicitly reproduce the 'list-item' behavior. I don't think it's reasonable to allow people to ignore 'list-item' for the CSS inherent behavior, but require them to pay attention to it for the HTML inherent behavior.

[fantasai]

As a general principle, I prefer to minimize the amount of magic in CSS that depends on document semantics: if we can describe HTML's behavior using CSS mechanisms, where HTML's interaction is limited to injecting regular CSS declarations into the cascade rather than applying specialized knowledge of the HTML vocabulary during layout / at used-value time, I think that's better.

Let's be clear the issue here isn't about list-item increments in general: the default increment that we apply to list-item display types works fine for HTML list numbering in almost all cases. The exception is for reversed lists, and I think it's fine to handle that through the UA style sheet. I don't think it's factual to say that it "doesn't work": it clearly does work, and there aren't, as far as I am aware, any web-compat concerns with doing it that way.

If there's a problem with reversing list numbering through a rule like ol { counter-increment: list-item -1; }, then I think we should take @FremyCompany's suggestion in #3686 (comment) and introduce a property to control the automatic increment, e.g. ol { list-increment: -1; }. But I think reversed lists are unusual enough that just using counter-increment rule should be sufficient.

CC @MatsPalmgren @dbaron @domenic

[tabatkins]

If we want to explain the magic via a brand new property (which wouldn't have cascading or backcompat problems), that's fine. I don't think it's useful enough to be worth doing, but whatever; I'm not opposed.

But I don't like the idea that you can definitely set counter-increment: foo 1; on a normal li and it'll continue to number itself perfectly correctly, but if that li is in an <ol reversed> you'll screw up the numbering.

Either both forward and reverse numbers should work magically, regardless of what other stuff you set in counter-increment, or both should fail to work, imo.

[emilio]

The issue why you can't do ol[reversed]>li is because it's not li what you should target, but "anything with a computed display value of list-item".

[emilio]

Also need to be arbitrary descendants. So in this case, while unfortunate, it needs to be through magic. In Gecko that magic is a -moz-list-reversed inherited property, see:

https://searchfox.org/mozilla-central/rev/9775cca0a10a9b5c5f4e15c8f7b3eff5bf91bbd0/layout/style/res/html.css#582

We could standardize it, but I think I agree with Tab that it seems to have limited utility.

[FremyCompany]

If a controlling property already exists, we probably should standardize it. Otherwise that behavior would remain unexplained in the spec.

[tabatkins]

It's not unexplained if the spec explains it in sufficient detail. ^_^

[MatsPalmgren]

(Just to clarify, -moz-list-reversed is a Gecko internal property that isn't exposed to web content, so it's merely an implementation detail.)

If we add support for reversed lists in CSS then I think we should consider generalizing it to all counters. There would actually be some utility in that for authors, since the most important aspect of <ol reversed> is that the start ordinal is automatic based on the content. That can't be achieved for other counters currently.

Also, a new inherited property might not be the best way to add this feature. It was convenient to implement it like that when the automatic counter-increment for list items was a computed value, but #3686 changed that to used-value time, so we could probably remove this property now. (It might be better to extend counter-reset in some way instead, if we standardize this.)

[tabatkins]

The problem is that we're barred from the obvious methods of extending counter-reset, due to the historical lack of commas. counter-reset: foo reversed;, for example, just resets two counters, foo and reversed.

We could do more complex stuff, like stuffing new values into a function or something.

[tabatkins]

If we were to consider that, tho, hmmm. We've talked before about having a way to count the number of children an element has, and use that to initialize counter-reset for reversed lists. But as Emilio points out, that's not actually sufficient; arbitrary descendants can use that list counter.

So I'm thinking the way to go is to iterate thru all the elements in the scope, counting the display:list-item elements that have the counter in question in scope (that is, it's the last counter of that name in the element's counter set, and thus possible to be set/incremented by them). That's pretty magic, but I think it's the degree of magic we need to achieve this functionality.

[fantasai]

@tabatkins Please file a separate issue on the start value of reversed lists. This issue is about increments specifically (and intentionally).