Update the Rendering section for Lists to use the built-in 'list-item…

[MatsPalmgren]

As requested by @domenic in w3c/csswg-drafts#4168

• At least two implementers are interested (and none opposed):
  • Chromium (Update the Rendering section for Lists to use the built-in 'list-item… #4816 (comment))
  • Gecko implements part of this (not yet reversed()) (@emilio @MatsPalmgren )
  • No signal yet from WebKit
• Tests are written and can be reviewed and commented upon at:
  • HTML: Test rendering of ol, ul, menu, li, dir, dl, dt, dd web-platform-tests/wpt#28040
  • [css-lists] Test counter-reset: reversed() web-platform-tests/wpt#28453
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1198541
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1706346
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=224811
• Dependencies:
  • [css-lists] Define reversed counters with automatic initial value w3c/csswg-drafts#6096 (and follow-up [css-lists] Fix reversed counters to count how many elements increment or set the counter w3c/csswg-drafts#6297)

(See WHATWG Working Mode: Changes for more details.)

---

/infrastructure.html ( diff )
/rendering.html ( diff )

[MatsPalmgren]

Actually, it might be better skip the last paragraph that I added (about <ol reversed>) and add that bit to CSS Lists instead since it affects the CSS used value, not the computed value. Also, it should probably be inhibited by contain:style as discussed in #4808 and we can include that too in CSS Lists so that there is one place that defines how the default value for the built-in list-item counter is determined. We can add a note here about <ol reversed> that links to that definition instead. WDYT?

[domenic]

Can you ensure that the result builds?

I noticed that you deleted the pull request template. Can you edit your OP to reinstate it? It contains important information for determining whether we'll be able to merge this, such as whether there are web platform tests for the normative changes, or multiple implementers lined up to implement it.

Actually, it might be better skip the last paragraph that I added (about <ol reversed>) and add that bit to CSS Lists instead since it affects the CSS used value, not the computed value.

It's unclear to me whether the CSS specifications want to take dependencies on HTML elements, and specific HTML element names, in this way, or whether they want to be agnostic to the "host language". So far from what I've seen of CSS they prefer being agnostic, but you would probably have more experience than I.

[zcorpan]

I've revamped this to address @domenic's comments, and to make <ol reversed> be rendered in terms of the yet-to-be-defined feature counter-reset: reversed(list-item). See w3c/csswg-drafts#4211 (comment)

[domenic]

Very nice work; thanks for this!

Could you say a bit more about the comparison with https://drafts.csswg.org/css-lists/#ua-stylesheet ? Specific things I wonder about:

• ul { list-style-type: toggle(disc, circle, square); }
• marker-side: match-parent; on ol, ul
• text-align: match-parent; on li
• The use of attr() and calc() instead of your algorithmic approach, and what the differences are.

[domenic]

This algorithm is very nice and simple and clean. I worry a bit about whether it is in sync with the "ordinal value" definition. But, I can't think of any nice way to keep them in sync and make sure they reflect the same thing, because it's really comparing ordinal value to (this algorithm + CSS's automatic features like list-item incrementing).

Let me know if you have thoughts about ordinal value. Before, we spent effort defining ordinal value based on UA behavior to match the rendered output. Now that UA rendering is defined entirely in terms of CSS (and can, e.g., get out of sync with ordinal value via manually setting various CSS properties), it's not clear how to think of ordinal value's role. It gives a sense of what the semantics of the list are, but is it really OK for those semantics to drift visibly from the rendering? Which would we expect accessibility technology to use?

[zcorpan]

Yeah ordinal value was indeed supposed to match browsers' rendering behavior, but now that mapping to CSS properties can do that, there's not so much of a need for ordinal value to do that. We could take the opportunity to completely decouple the semantic numbering from CSS. That CSS can be used to give a completely different visual compared to the semantics of the HTML is nothing new, and isn't an issue. On the contrary, having author CSS affect underlying semantics is against the spirit of CSS. I'll file an issue about ordinal value. (edit: #6473)

[zcorpan]

Which would we expect accessibility technology to use?

ATs generally take CSS into account (e.g. don't expose display: none, do expose generated content), but there are tricky cases (like <td style="display: block"> should still be exposed cells in a data table, while <div style="display: table"> should not be exposed as a data table). For counters, I think users would expect the numbers to match visual rendering.

[fantasai]

See https://www.w3.org/TR/css-counter-styles-3/#counter-style-speak-as

[zcorpan]

@fantasai interesting, thanks! Even with speak-as, though, the question is which number an AT should use -- the semantic number based on the HTML alone (or some combination of HTML+CSS), or the number the list item has per CSS counters?

[annevk]

Maybe we can make it similar to the various bidi features, that have this language:

The following elements and attributes have requirements defined by the rendering section that, due to the requirements in this section, are requirements on all user agents (not just those that support the suggested default rendering)

[zcorpan]

@annevk I filed #6599 to track this

[zcorpan]

@domenic

Very nice work; thanks for this!

Thank you!

Could you say a bit more about the comparison with https://drafts.csswg.org/css-lists/#ua-stylesheet ? Specific things I wonder about:

• ul { list-style-type: toggle(disc, circle, square); }

This doesn't match what browsers do -- a nesting of e.g. ol ul gives a circle marker, but this rule would give a disc marker, if I understand correctly.

https://html.spec.whatwg.org/multipage/rendering.html#lists
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/9010

• marker-side: match-parent; on ol, ul
• text-align: match-parent; on li

We could add these here, or in a follow-up. I haven't yet looked into what these do exactly.

• The use of attr() and calc() instead of your algorithmic approach, and what the differences are.

So with this

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

The value would be parsed with CSS rules instead of HTML rules, which makes a difference for e.g. start="1e10" or start="10xyz".

[domenic]

Awesome, that all makes sense. It'd be great to have tests for the start="1e10" or start="10xyz" cases to ensure nobody ever tries to switch their implementation to using attr().

[domenic]

LGTM. Will need tests, which should help inform implementation interest.

Also, @MatsPalmgren can you join https://github.com/mozilla-standards and publicize your membership therein?

[zcorpan]

I've filed browser bugs for this now, listed in OP. The spec change to CSS Lists needs review and CSS WG approval, and the tests for reversed() need review.

Also need clarify on implementer interest, which I think there is from Gecko and Chromium but I'm not the one to sign off on that.

[domenic]

@mfreed7 and/or @chrishtr are probably the right person to confirm for Chromium.

[chrishtr]

Yes there is Chromium interest. I think @emilio also indicated Gecko interest, and I believe in fact Gecko already implements
lists using the CSS machinery.

[zcorpan]

w3c/csswg-drafts#6096 was merged, so I think this should be ready.

@smfr can you comment regarding interest/opposition for WebKit?

[zcorpan]

One week has passed. Should we merge?

[annevk]

Do you have a proposed commit message?

[zcorpan]

Define rendering of <ol><li> numbers in terms of CSS Lists

Map `<ol start reversed>` and `<li value>` to `counter-reset` and `counter-set`
properties as presentational hints. For reversed lists, use the CSS `reversed()`
function added in https://github.com/w3c/csswg-drafts/pull/6096

Tests:
https://github.com/web-platform-tests/wpt/pull/28040
https://github.com/web-platform-tests/wpt/pull/28453

I'm not certain whether #4808 is fixed by this PR, though technically it's up to CSS to define the interaction between contain: style and counters. (cc @vmpstr)