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.

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

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.

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".

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.

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

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

(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.)

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.

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.

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

The CSS Working Group just discussed Should automatic list-item increment adjust for ol[reversed]?.

Regarding setting the initial value of a reversed list, I'd originally felt you could do this in pure CSS with a new function count(), which takes a selector and returns the number of elements that match it when evaluated on the current node: so exactly the same as :has(), but returning an ordinal value.

You could have something like:

ol[reversed] {
    counter-reset: list-item calc(attr(start integer, count(> li)) + 1);
}

However the comment from @emilio above, that this must count the items with display:list-item not just li, made me think believe it couldn't work. But its just dawned on me that it can, like so:

ol[reversed] {
    counter-reset: list-item calc(attr(start integer, count(> ::marker)) + 1);
}

There are numerous uses for a count() function in CSS - imagine the javascript-free layouts you could create, using only calc, count and the new trignometric functions going into css-values.

If we aren't dealing with a Web-compat issue over numbering list-item descendants of an ol[reversed] that aren't li elements, I think my preference here would be to define a list-increment property that increments a list-item counter but only on display: list-item boxes.

Then the UA style sheet can say ol[reversed] > li { list-increment: -1; }⁠—and also anyone who wants to turn off the increment can write X { list-increment: none; }, which would not disturb any counter-increment declarations or instantiate a superfluous list-item counter (that might then show up in li:marker { content: counters(list-item, ".") }, which is a little nice.

Wrt Web-compat, I don't think structures like the following are particularly common? This is what would change⁠—because we wouldn't be reversing the numbering on that DIV.

<ol reversed>
  <li>three
      <div style="display: list-item">two</div>
   <li>one
</ol>

@fantasai I agree there's probably not much of a web-compat problem with arbitrary descendant non-<li> elements styled as display:list-item. But the issue is that <li>s might be wrapped, like so:

<ol reversed>
  <font>
    <li>A</li>
    <li>B</li>
    <li>C</li>
  </font>
</ol>

I suspect that's common enough that we need to handle it and your ol[reversed] > li rule above wouldn't work for this case. (Also, that rule would give a non-default computed value for <ol reversed><li style="display:block"> which seems unfortunate, but probably doesn't matter in practice.)

I still think implementing this as a preshint that maps <ol reversed> to counter-reset: reversed(list-item) or some such and making that imply a default counter-increment value of -1 in layout is the best solution.

See PR #6096 for a proposal to address this (and discussion in #4211).