Intent to implement and ship: built-in CSS counter 'list-item'

[Mats Palmgren]

Summary:
The built-in 'list-item' counter is used to implement HTML <ol>/<li>
(and other elements with display:list-item) using CSS.

I'm also removing our old (frame-based) code for list item counters,
which had a number of decades-old bugs (bug 4522 et al), was rather
slow (bug 3246) and crashy (bug 1515124).

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=288704

Link to standard:
https://drafts.csswg.org/css-lists/#declaring-a-list-item

Platform coverage: All platforms

Estimated or target release: Firefox 68

Preference behind which this will be implemented: none

DevTools bug: none

Do other browser engines implement this?
No, as far as I can tell.

web-platform-tests:
I added a couple of WPTs in css/css-lists/ and there are some
in css/CSS2/lists which we now pass. Also, given that we now
use this built-in counter for all display:list-item elements
we should have basic coverage from existing tests for those.

Is this feature restricted to secure contexts? No


/Mats

[Mats Palmgren]

[Domenic Denicola]

Some time ago we spent some effort documenting a cross-browser mostly-interoperable behavior for list-item-like behaviors, in https://github.com/whatwg/html/pull/2002 and linked threads. The result is the spec at https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and the tests at https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element .

The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems to contradict that hard-fought consensus. It states simply that

> Additionally, list items automatically increment the special list-item counter. Unless the counter-increment property manually 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.

This omits all the details at https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , e.g. reversed="", the collection of owned list items, value="" attribute parsing, etc.

It seems like a regression to implement list item numbering according to that spec, instead of according to HTML.

> web-platform-tests:

An important thing to test here is the result of getComputedStyle on list items as a result of this change. HTML specifies that ordinal values are displayed on list items without any counter CSS properties involved, and from what I can tell, https://drafts.csswg.org/css-lists/ does not change that. (The appendix at https://drafts.csswg.org/css-lists/#ua-stylesheet is informative, not normative.) So, including tests that getComputedStyle continues to return no results for the counter-related properties or pseudo-elements seems important to maintaining interop on this front.

[Domenic Denicola]

On Sunday, March 24, 2019 at 10:21:10 PM UTC-7, Domenic Denicola wrote:


> the tests at https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element

correction, https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-li-element is where most of the tests landed. The pull request was https://github.com/web-platform-tests/wpt/pull/4169 .

[Emilio Cobos Álvarez]

On 25/03/2019 06:21, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser mostly-interoperable behavior for list-item-like behaviors, in https://github.com/whatwg/html/pull/2002 and linked threads. The result is the spec at https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and the tests at https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element .
>
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems to contradict that hard-fought consensus. It states simply that
>
>> Additionally, list items automatically increment the special list-item counter. Unless the counter-increment property manually 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.
>
> This omits all the details at https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , e.g. reversed="", the collection of owned list items, value="" attribute parsing, etc.
>
> It seems like a regression to implement list item numbering according to that spec, instead of according to HTML.

FWIW, the check-in fixing this[1] fixed multiple WPT tests related to
this, and regressed none, see the .ini file changes.

>> web-platform-tests:
>
> An important thing to test here is the result of getComputedStyle on list items as a result of this change. HTML specifies that ordinal values are displayed on list items without any counter CSS properties involved, and from what I can tell, https://drafts.csswg.org/css-lists/ does not change that. (The appendix at https://drafts.csswg.org/css-lists/#ua-stylesheet is informative, not normative.) So, including tests that getComputedStyle continues to return no results for the counter-related properties or pseudo-elements seems important to maintaining interop on this front.

I agree that testing this seems useful, but I disagree on it being
ignored in computed style serialization of all counter-* properties,
that feels rather magical.

I agree that the counter-increment should be ignored in computed style
serialization (I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1539171 to fix that).

Note that <li value=""> attribute parsing hasn't changed, and it's just
a mapped attribute mapping to counter-set. I don't think this conflicts
with the HTML spec, and I think that we should keep <li value="">
serializing counter-set in getComputedStyle. I don't think there are
interop concerns for counter-set since counter-set is not implemented in
other engines, but attribute mapping is straight-forward and works
similarly everywhere.

-- Emilio

[1]: https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[L. David Baron]

On Sunday 2019-03-24 22:21 -0700, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser mostly-interoperable behavior for list-item-like behaviors, in https://github.com/whatwg/html/pull/2002 and linked threads. The result is the spec at https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and the tests at https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element .
>
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems to contradict that hard-fought consensus. It states simply that
>
> > Additionally, list items automatically increment the special list-item counter. Unless the counter-increment property manually 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.
>
> This omits all the details at https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , e.g. reversed="", the collection of owned list items, value="" attribute parsing, etc.
>
> It seems like a regression to implement list item numbering according to that spec, instead of according to HTML.

I wouldn't expect any of these features or tests to regress as a
result of this. (That said, I think it may be worth considering
behavior changes to edge cases, if such changes are needed,
particularly where browsers aren't currently interoperable, in order
to move towards the idea of list numbering being implemented with
CSS counters underneath.)

I'd note that the sample style sheet for HTML in CSS Lists does
attempt to describe what is needed for HTML:
https://drafts.csswg.org/css-lists/#ua-stylesheet
although it admits that the CSS counter model on its own can't
describe reversed.

The web-platform-test test expectation changes in
https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4 are (except
for a single test) in the direction of improvement.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Domenic Denicola]

It's great to hear that this isn't a regression in the way I expected. I think I was thrown off by the phrasing of the OP, which implied to me a switch from following the HTML spec to following the CSS lists spec. As I noted, the CSS lists spec contradicts the HTML spec, e.g. disallowing reversed="" from affecting the counter values. But it sounds like you're ignoring that part of the CSS spec, and instead incrementing (setting?) the list-item counter according to the HTML spec's rules.

I remain a bit concerned that the behavior you're implementing here is not reflected in any spec at all. This would not matter if this were just internal implementation refactoring. However, it's observable to the web via getComputedStyle().

Note that the complete list of allowed-per-spec default style changes for li elements is given by https://html.spec.whatwg.org/multipage/rendering.html#lists , and per https://github.com/web-platform-tests/wpt/issues/5625 the CSSWG declared the intent to test these requirements via web platform tests.

Introducing new observable behavior with no spec backing, or even opening an issue on the relevant specs, seems bad. Reading between the lines, it seems to be Mozilla's position that HTML should change to add some CSS rule to the user agent stylesheet which modifies counter-set, but not counter-increment. If so it'd be much appreciated if folks would open an issue on whatwg/html for public standards discussion and work toward cross-browser consensus.

[L. David Baron]

On Tuesday 2019-03-26 14:25 -0700, Domenic Denicola wrote:
> It's great to hear that this isn't a regression in the way I expected. I think I was thrown off by the phrasing of the OP, which implied to me a switch from following the HTML spec to following the CSS lists spec. As I noted, the CSS lists spec contradicts the HTML spec, e.g. disallowing reversed="" from affecting the counter values. But it sounds like you're ignoring that part of the CSS spec, and instead incrementing (setting?) the list-item counter according to the HTML spec's rules.

I don't think there's an actual contradiction. The spec describes
the default behavior of list items, but then specifies that other
things happen through the values of CSS properties that are in the
UA stylesheet. This is the normal way that things evolve when CSS
adds a CSS explanation for an existing feature and part of that CSS
explanation lives in the UA stylesheet.

This has been under discussion in the CSS working group for... over
a decade now, so I wouldn't say that there hasn't been any
cross-browser discussion of it.

That said, the specs could certainly coordinate better.

[jacka...@gmail.com]

Note that the spec does not yet reflect the decisions made at the last F2F, or the subsequent decisions from Issues.

[Mats Palmgren]

On 3/25/19 6:21 AM, Domenic Denicola wrote:
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item

> seems to contradict that hard-fought consensus. It seems like a

> regression to implement list item numbering according to that spec,
> instead of according to HTML.

As others have clarified, there are zero regressions from these changes
(that we know of) and **a lot** of bugs fixed. The compatibility with
other UAs and web content is now greatly improved.

You seem to think that HTML is the authoritative specification for
how list items work. That's only partly true.
HTML specifies the part where certain elements opens a list item
scope (ol/ul/menu), have a default 'display:list-item' value (li)
and that <li value=N> sets the value of the counter, etc.

However, the actual semantics for how list items work are
exclusively defined by CSS ([css-lists], [css-pseudo]).
The above mentioned HTML elements/attributes simply maps to
the relevant CSS properties, using a built-in 'list-item' counter.
Most importantly: this counter behaves **exactly** the same as any
other CSS counter would for a given set of style values.
We're simply not going to add a parallel "HTML counter" implementation
that is incompatible with CSS counters just to implement these HTML
elements (in fact, we've just removed the special counting we had).

Mapping HTML lists to CSS has **major** benefits for authors and
implementors alike. I'd be happy to elaborate on that if you wish.


> This omits all the details at [...], e.g. reversed="", the collection

> of owned list items, value="" attribute parsing, etc.

<li value> is mapped to the 'counter-set' property.

<ol reversed> is the one thing that isn't yet defined fully in a CSS spec.
We have implemented it using an internal (not exposed to web content)
inherited CSS property, and then map the attribute to that.

So, what our new implementation proves is that all of HTML's funky list
items can be fully and exclusively implemented using CSS concepts.
Well, we hope so anyway. We'll know after it hits the release channel :-)

> An important thing to test here is the result of getComputedStyle on
> list items as a result of this change. HTML specifies that ordinal
> values are displayed on list items without any counter CSS properties
> involved

Emilio filed https://github.com/w3c/csswg-drafts/issues/3769 about this.
I disagree that getComputedStyle should lie about the actual value
of any of the counter-* properties. I see no benefit to anyone
in doing that and I also don't think it's needed for web-compatibility.


Regards,
Mats

[css-lists]
https://drafts.csswg.org/css-lists/

[css-pseudo]
https://drafts.csswg.org/css-pseudo/

[Domenic Denicola]

(On-list this time)

> However, the actual semantics for how list items work are exclusively defined by CSS ([css-lists], [css-pseudo]).
> The above mentioned HTML elements/attributes simply maps to the relevant CSS properties, using a built-in 'list-item' counter.

Where does [css-lists] and [css-pseudo] define this?

[Mats Palmgren]

From CSS Lists, Introduction:
https://drafts.csswg.org/css-lists-3/#intro
"It also defines _counters_, which are special numerical objects
often used to generate the default contents of markers."
where _counters_ links to:
https://drafts.csswg.org/css-lists-3/#counter

Pretty much all of CSS Lists is about how these generic
counters work. The built-in 'list-item' is such a counter.
The only thing special about it is that it's automatically
incremented for any element that has 'display:list-item'.
https://drafts.csswg.org/css-lists-3/#declaring-a-list-item
Other than that, it works exactly like a counter an author
can introduce themselves.

FYI, the CSS Lists spec isn't very well maintained, sadly,
so it's not up-to-date with recent resolutions. So, some
of the finer details in there might be wrong, but I think
most of it regarding counters is correct.


/Mats

[L. David Baron]

On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:
> FYI, the CSS Lists spec isn't very well maintained, sadly,
> so it's not up-to-date with recent resolutions. So, some
> of the finer details in there might be wrong, but I think
> most of it regarding counters is correct.

If you've been implementing based off of resolutions that aren't in
the spec, it's probably worth submitting PRs to the spec so that
other future implementors are aware of those resolutions and you
don't have to later go and undo the effects of those resolutions for
compatibility.

[fantasai]

On 3/27/19 5:19 AM, L. David Baron wrote:
> On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:
>> FYI, the CSS Lists spec isn't very well maintained, sadly,
>> so it's not up-to-date with recent resolutions. So, some
>> of the finer details in there might be wrong, but I think
>> most of it regarding counters is correct.
>
> If you've been implementing based off of resolutions that aren't in
> the spec, it's probably worth submitting PRs to the spec so that
> other future implementors are aware of those resolutions and you
> don't have to later go and undo the effects of those resolutions for
> compatibility.

Since I just ran across this thread, current status of the spec is a lot better:
https://lists.w3.org/Archives/Public/www-style/2019Apr/0024.html

~fantasai