[css-lists] Can replaced elements be list items?

[Loirooriol]

From https://drafts.csswg.org/css-lists/#list-item,

A list item is any element with its display property set to list-item. List items generate ::marker pseudo-elements

What if you have

<ol>
  <svg style="display: list-item"></svg>
  <li>item</li>
</ol>

The <svg> has display: list-item, but it's a replaced element, so it can't originate a ::marker pseudo-element inside. Then, should we still consider it to be a list item that increments the list-item counter?

In Chromium it's not considered to be a list item, so it shows 1. item. This also used to be the case in Firefox until bug 288704 and bug 1539267, now Firefox shows 2. item.

IMO the Firefox behavior seems confusing. Because if I have

<ol>
  <div style="display: none">
    <svg style="display: list-item"></svg>
  </div>
  <li>item</li>
</ol>

then the <svg> still has a computed display value of list-item, but now it shows 1. item like Chromium. So it's not just checking the computed display, I guess it's also checking for being rendered.

For me it makes more sense to require list items to be non-replaced elements. Then (assuming you are not preventing the ::marker from generating boxes via list-style-type or content), if there is a marker box then it means it's a list item, otherwise it's not.

CC @MatsPalmgren @emilio @fantasai

[emilio]

Well, the "being rendered" bit is true for all counter-incrementing / counter-resetting things, right?

[emilio]

(Also note that Gecko matches what EdgeHTML used to do, too)

[Loirooriol]

Oh, I missed https://drafts.csswg.org/css-lists/#counters-without-boxes

An element that does not generate a box (for example, an element with display set to none, or a pseudo-element with content set to none) cannot set, reset, or increment a counter.

So I guess an element with display: list-item inside a display: none may be considered to be a list item but is not able to increment the list-item counter.

The section also says

Whether a replaced element’s descendants (such as HTML option, or SVG rect) can set, reset, or increment a counter is undefined.

but replaced elements themselves are not included, so presumably they must be able to affect counters.

Then Firefox is following the spec. And thinking more about this, I guess that behavior is more reasonable given how the list-item counter is supposed to behave (it's so buggy in Chromium, since it's not a real counter). So OK.