[css-lists] <reversed-counter-name> <integer> seems useless

[Loirooriol]

#6096 added the reversed() syntax to the counter-reset property.

However, unless I'm missing something, these are totally equivalent:

counter-reset: c 7;
counter-reset: reversed(c) 7;

The only difference is that the latter instantiates the counter with a reversed flag, but this flag only seems relevant in these cases:

• When omitting the starting value (it's 7 in the example)
• In the implicit list-item counter (it's c in the example)

So IMO we have two reasonable possibilities:

• Drop the useless <reversed-counter-name> <integer> syntax, and just keep <reversed-counter-name>.

  The reversed flag of the counter would then be set by <reversed-counter-name> and also when counter-reset instantiates a list-item counter in an <ol reversed>. The preshint for reversed HTML lists would be:

  ol[reversed] {
    counter-reset: reversed(list-item);
  }
  ol[reversed][start] {
    counter-reset: list-item calc(attr(start integer) + 1); /* with reversed flag */
  }

• Keep <reversed-counter-name> <integer>, but then negate increments not just to list-item but to all counters. That is, list-item counters would get counter-increment: list-item 1 by default, not -1 for reversed lists. And when incrementing a reversed counter, the specified amount would actually be decremented. So

  <style>
  #parent { counter-reset: reversed(c) 7; }
  #parent > .child { counter-increment: c 2 } /* Decrements since the counter is reversed */
  #parent > .child::before { content: counter(c) ". " }
  </style>
  <div id="parent">
    <div class="child">foo</div>
    <div class="child">bar</div>
  </div>

  would look like

  5. foo
  3. bar
  

The latter seems more useful for authors, and makes list-item less magic.

[MatsPalmgren]

ol[reversed][start] {
counter-reset: list-item calc(attr(start integer) + 1); /* with reversed flag */
}

I'm confused - how could that possibly work? - the computed value will be the same as a non-reversed counter since the "with reversed flag" isn't encoded in the computed value. E.g. <ol reversed start=8> would have the same computed counter-reset value as <ol start=10>, right? That doesn't make sense to me. Also, we should definitely provide a way to express <ol reversed start=8> in pure CSS and map the HTML attrs to that. No magic flags that can only be set by HTML please. So the first option is unacceptable IMO.

Your second suggestion is interesting, but I doubt it's web-compatible. I suspect there's a lot of existing content that use <ol reversed> together with explicit counter-increment: list-item -1 (and other values), which would break if we change the meaning of the sign.

I tend to think we should keep the syntax as is. You're right that the reversed() keyword doesn't really do anything for the specific case you mention, except perhaps as for documentation purposes, but that seems like a minor issue. I think I prefer to keep the syntax/serialization uniform for all counters rather than introducing special cases. And who knows, maybe we'll find a use for the explicit reversed() in this case too in the future? E.g. counter-increment: c step(2) which could mean 2 or -2 depending on the context...

That said, in theory we could make a default increment value for non-list-item counters be 1 or -1 depending on context. E.g.

container { counter-reset: reversed(c) 7; }
item  { counter-increment: c; }

given that we don't have any backwards compat to worry about here. That complicates the spec a bit though - which currently says the value defaults to 1. It's also more for authors to learn since non-list-item default values would behave differently from list-item. I think simplicity/uniformity is probably preferable here too - after all it's just a "-1" to type out, and an explicit value is also clearer.

[Loirooriol]

No magic flags that can only be set by HTML please.

Yes, it would need magic to set the reversed flag. But now we already have some magic in order to produce either counter-increment: list-item 1 or counter-increment: list-item -1.

Your second suggestion is interesting, but I doubt it's web-compatible.

I think it's probably web compatible. Chromium completely ignored counter-increment and counter-set for list-item counter (except in content: counter(list-item)) until 89.0.4353.0 https://crrev.com/835809. And this was changed just to implement <summary> as a list item with counter-increment: list-item 0, not because authors were complaining the functionality was broken. So I doubt there's a lot of existing content relying on counter-increment: list-item X.

E.g. counter-increment: c step(2) which could mean 2 or -2 depending on the context

Not a bad idea. But then maybe <reversed-counter-name> <integer> should wait until we have something like that. Otherwise it seems confusing to be able to declare reversed lists that completely behave like non-reversed ones.

[Loirooriol]

I think it's probably web compatible. Chromium completely ignored counter-increment and counter-set for list-item

Though I guess some pages might be using reversed for semantics, but then using their own counter (different than list-item) in order to have more control and avoid browser bugs. That custom counter would then have negative counter-increment in order to get the reversed effect, which my proposal would break.

[Loirooriol]

E.g. counter-increment: c step(2) which could mean 2 or -2 depending on the context

Filed #6800 for this.