[css-lists] Contradictory normative requirements for implicit 'list-item' counter?

[domenic]

https://drafts.csswg.org/css-lists-3/#list-item-counter

Unless the counter-increment property explicitly specifies a different increment for the list-item counter, it must be incremented by 1 on every list item, at the same time that counters are normally incremented.

but then later

UAs and host languages should ensure that the list-item counter values reflect the underlying numeric value dictated by host language semantics when setting up list item styling in their UA style sheet and presentational hint style mappings.

Not really sure how to word this requirement, but the following example is expected to work.

In particular consider cases like <ol reversed> or <li value="">. The host language specifies an algorithm for figuring out the "underlying numeric value". But that value decreases. This seems to contradict the above "must" that it be incremented by 1.

[domenic]

Another question, but I'll put it in the same issue for now: how does the "UA and host languages" requirement interact with counter-increment?

For example, given

<ol>
  <li>First top-level item
  <li value=5>Second top-level item, value=5
    <ol start=3>
      <li>First second-level item, list start=3
      <li>Second second-level item, list start=3
         <ol reversed>
           <li>First third-level item in reversed list
           <li>Second third-level item in reversed list
           <li>Third third-level item in reversed list
           <li>Fourth third-level item in reversed list
         </ol>
      <li>Third second-level item, list start=3
  <li>Third top-level item
</ol>

plus

ol::marker { content: counters(list-item,'.') '.'; }
ol { counter-increment: list-item 2; }

what happens?

[fantasai]

It's worth looking a little more closely at what this requirement is trying to say:

UAs and host languages should ensure that the list-item counter values reflect the underlying numeric value dictated by host language semantics when setting up list item styling in their UA style sheet and presentational hint style mappings.

For HTML, "setting up list item styling in their UA style sheet and presentational hint style mappings" will need to correspond to something like (and I'm not yet entirely sure of these rules):

ol[reversed] > li { counter-increment: list-item -1; }
ol[reversed] { counter-reset: list-item calc(<child-count>+1); }  /* alternately counter-set */
ol[start] { counter-reset: list-item calc(attr(start integer) - 1); } /* alternately counter-set */
li[value} { counter-set: list-item attr(value integer); }

There needs to be a "by default" in that sentence, so I'll fix that at least.

For example, given ... what happens?

I'll assume you meant those selectors to be li rather than ol?

Most of the example you give is pretty straightforward if we take the idea that list-item counters are set up by the UA, and they're overrideable by authors. What's interesting is what happens when one applies counter-increment: list-item 2 to a reversed list. It'll definitely be weird...

CC @MatsPalmgren

[domenic]

For HTML, "setting up list item styling in their UA style sheet and presentational hint style mappings" will need to correspond to something like (and I'm not yet entirely sure of these rules):

Right, OK, my bad. I totally missed that the "should" requirement specifies a particular mechanism to be used. I guess in that case HTML is not currently following the "should" requirement.

Do you think it's a problem that it seems impossible for HTML to follow the "should" requirement without magic child counters, or other unspecified mechanisms?

I'll assume you meant those selectors to be li rather than ol?

I'm not sure. Example 16 applies counter-increment to ol.evens, and example 17 applies content: to ol::marker. Maybe those are just typos.

[tabatkins]

Maybe those are just typos.

Yes, they were. Fixed.

[fantasai]

@domenic

Do you think it's a problem that it seems impossible for HTML to follow the "should" requirement without magic child counters, or other unspecified mechanisms?

I think it's better to have it mostly implemented via CSS mechanisms with very limited magic than completely implemented by magic. I believe this in principle, but also it has major benefits to authors, because it allows them to adjust the styling without having to recreate all of its behavior from scratch (while also suppressing the browser's default rendering). I think the examples in https://drafts.csswg.org/css-lists-3/#list-item-counter demonstrate this well: trying to recreate the x.y.z numbering style without being able to hook into the list-item counter would be much harder, particularly if one wanted to handle the start and value attributes correctly—and for the reversed list, wouldn't even be possible.

[domenic]

I don't feel like that really answered my question though. In particular, how is HTML supposed to fulfill the "should" requirement? I can't understand how, unless "UA style sheet and presentational hint style mappings" are allowed to use magic (which I think would be unprecedentedno, I guess there's precedent, e.g. "if parsing fails use a default value" seems pretty magic for <table border> <-> border-*-width mapping).

We have one proposed set of edits in https://github.com/whatwg/html/pull/4816/files, but it uses a lot of undefined terminology and unprecedented mechanisms, which I'm unsure how we should proceed with.

[tabatkins]

I need to go review that PR, thanks for your patience.

I've been slightly tweaking the wording of the spec; currently it should be a lot clearer that incrementing the 'list-item' counter is definitely magic (with a default of +1 per list item, but allowing host languages to dictate whatever is in accordance with their semantics, specifically for reversed), and is not achieved thru UA stylesheets. I've made sure that the recommended stylesheet doesn't set 'counter-increment' on any element (it just has comments where an effective counter-increment is expected).

[fantasai]

@tabatkins I'm not convinced that the automatic counter increment needs to be magically tied to the document semantics. It works fine if it's done through the UA style sheet. If you think it needs to be magic, let's file an issue so we can discuss it.

@domenic

I don't feel like that really answered my question though. In particular, how is HTML supposed to fulfill the "should" requirement? I can't understand how, unless "UA style sheet and presentational hint style mappings" are allowed to use magic

There's all kinds of magic in how HTML defines rendering, from special rules for parsing colors to layout effects that aren't possible using pure CSS. There's some interesting questions on what's the best way to handle the start value of a reversed list, but other than that the mappings needed here are relatively simple to define either through the UA style sheet or as presentational hints, as appropriate.

We have one proposed set of edits in https://github.com/whatwg/html/pull/4816/files, but it uses a lot of undefined terminology and unprecedented mechanisms, which I'm unsure how we should proceed with.

I've looked at the PR, it looks pretty reasonable. It needs some work to get the terminology straightened out and stuff, but nothing there seems outrageously unprecedented from my perspective. I'm happy to work with Mats on getting it in better shape.

[fantasai]

Moved discussion of whether ol[reversed] increments should be in the UA style sheet or magically hooked into CSS via Special Host Language Knowledge into #4181

[fantasai]

Filed issue of the reversed list start value at #4211