[css-lists] Omitted start value of reversed list isn't calculated right

From https://drafts.csswg.org/css-lists/#instantiating-counters,

When a counter is instantiated without an initial value, the user agent must dynamically calculate the initial value at layout-time to be the number of elements and pseudo-elements that instantiate the same counter in the same scope, plus 1.

Imagine a simple

<ol reversed>
  <li>foo</li>
  <li>bar</li>
  <li>baz</li>
</ol>

There is a singe element instantiating list-item: the <ol>. The <li> don't instantiate it since they only use counter-increment

The counter-increment and counter-set properties manipulate the value of existing counters. They only instantiate new counters if there is no counter of the given name on the element yet.

But precisely, what we want to count is the number of <li>. Or maybe the (negated?) sum of their counter-increments if they have been set to a value different than 1 (-1?). Something like that, not the number of instantiations.

@tabatkins

@tabatkins said the same in web-platform-tests/wpt#28453

But you only instantiate a counter when you're creating a new one. You want to instead count, I guess, the number of elements that affect the counter? Or perhaps pretend it starts at -1, accumulate all the increments it receives, then start it at the negation of the final result (so it'll end on 1)?

The intent was to make auto-reversed assume -1 increments, but making it end on 1 for arbitrary increments seems like the nicest behavior. Is this approach OK?

@MatsPalmgren @emilio @chrishtr @fantasai

Actually, I'm not sure it works. What if the last element uses counter-set or <li value>? Right now with <ol reversed> that doesn't change the start value of the list.

<ol reversed>
<li>foo
<li>bar
<li value=5>baz
</ol>

Gives 3, 2, 5 in current Chrome/Safari/Firefox.

[css-lists] Fix reversed counters to count how many elements incremen…

Good point, I didn't think of counter-set being used. I think I'd prefer the algo to stop at the first counter-set it encounters. So in your example, the first li would be 7.

(The motivation for this is "what would you get if your elements were in the opposite order and the counter wasn't reversed".)

Here's a more complex example, with the counter value I'd expect in the text of each:

<ol reversed>
 <li>7
 <li>6
 <li value=5>5
 <li>4
 <li value=2>2
</ol>

@tabatkins

@tabatkins is it acceptable to change what the start value is compared to what browsers do today for <ol reversed>?

We'd be doing that if we take the counter-increment into account too, right?

I suspect it's fine, as <ol reversed> isn't commonly used right now, especially in conjunction with <li value>. But that's just my intuition.

The proposed fix in #6297 has the same result as what browsers do now for <ol reversed> with <li value>.

I agree it seems likely to be rarely used, but we usually dig up data to confirm. However it's not clear to me why it's better to stop at the first element with counter-set. It seems kinda arbitrary to me? A non-reversed list doesn't change its start value when one of the list items use a value attribute. I would expect a reversed list to have the same start and end values, just reversed.

@fantasai

However it's not clear to me why it's better to stop at the first element with counter-set. It seems kinda arbitrary to me? A non-reversed list doesn't change its start value when one of the list items use a value attribute. I would expect a reversed list to have the same start and end values, just reversed.

@fantasai and I don't expect that. ^_^

Here's an example:

<ol reversed>
 <li>??
 <li value=20>20
 <li>??
 <li value=10>10
 <li>??
</ol>

I think it's pretty clear that the first ?? should be 21, so it can "count down" to 20. I believe you're with me on that.

But for the next two, we think they should be 19 and 9, not 11 and 1. We believe it's a stronger expectation for a reversed list's items, in the absence of any other fiddling, to just count down from the preceding item (just like normal lists count up), versus the expectation for a reversed list to be numbered identically to a normal list with reversed child order.

We also think it's important for <ol start=N> to have the same effect as <li value=N> on the first item, as in:

<ol reversed start=10>
 <li>10
 <li>9
</ol>

<ol reversed>
 <li value=10>10
 <li>9
</ol>

That definitely seems like a stronger expectation, at least to us.

Hmm, how embarrassing. I somehow had the wrong idea about how <li value> affects subsequent list items. I thought they didn't affect the next list item, but it does. I tested the example in #6233 (comment) but somehow must have glossed over the "4". :-/

That makes my previous expectation not very useful.

I agree that 21 for the first list item in that example would be ideal. Also, 19 and 9 matches what browsers do already.

So we are in agreement 👍

OK I've now updated #6297 so that it accumulates increments, counting the first element an extra time so that it gets the right value, and stopping at the first element using counter-set. I believe it matches what we discussed above.

It doesn't match up too well with <ol reversed start=10> when the <li> elements use a counter-increment other than -1 (such as -2 or -10), since HTML maps the start attribute to counter-reset: reversed(list-item) <start> + 1 and not counter-reset: reversed(list-item) <start> + <counter-increment-of-the-first-element>. But maybe that is OK?

I guess we already have that problem in

<ol start="5"><li style="counter-increment: list-item 3"></li></ol>

which produces 5-1+3 = 7 instead of 5.

@zcorpan

Yeah, I think that's an acceptable loss. Thanks for the update, @zcorpan!

Navigation Menu

Repository navigation

[css-lists] Omitted start value of reversed list isn't calculated right #6233

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-lists] Omitted start value of reversed list isn't calculated right #6233

Description

Activity

zcorpan commented on May 19, 2021

zcorpan commented on May 19, 2021

tabatkins commented on May 20, 2021

zcorpan commented on May 20, 2021

tabatkins commented on May 20, 2021

zcorpan commented on May 20, 2021

tabatkins commented on May 20, 2021

zcorpan commented on May 20, 2021

zcorpan commented on Jun 15, 2021

Loirooriol commented on Jun 15, 2021

tabatkins commented on Jun 15, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions