[css-display][css-pseudo] Is ::marker created by display:list-item or does it always exist?

[Loirooriol]

::before and ::after pseudo-elements always exist in the element tree, but most times they don't generate boxes in the box tree because content computes to none by default.

Is it similar for ::marker pseudo-elements? Do they always exist, but they only generate boxes if the display of the originating element has the list-item keyword? Or do ::marker pseudo-elements only exist if the originating element has the list-item keyword?

CSS Display handwaves the difference between the ::marker pseudo-element and the marker box generated by it, so it's not clear. CSS Pseudo isn't clear either.

The difference matters because Firefox and Chrome allow ::marker pseudo-elements to be originated by some tree-abiding pseudo-elements. So if ::marker always exist, this could potentially mean that the element tree has an infinite depth, which doesn't sound much right.

I see various possibilities:

• ::marker pseudo-elements are only created when display has the list-item keyword.
• ::marker always exist but are only originated by elements, ::before, and ::after. They can't be originated by other ::marker.
• ::marker always exist but are only originated by elements. Like ::before and ::after, they can't be originated by other pseudo-elements. This would be a breaking change for Firefox and Chrome.
• ::marker always exist and can be originated by elements or any tree-abiding pseudo-elements. The element tree has an infinite depth, but in practice this isn't much problematic because the box tree is finite.

[tabatkins]

Ah, I was inclined to say they always exist (but only generate boxes when display:list-item on the originating element), but your point about infinite trees is well-taken. (I mean, the element tree isn't observable, so it being infinite but only being allowed to generate finite box trees is theoretically okay, but awkward to talk about.)

I mean, ::marker pseudos can't ever generate meaningfully generate more ::markers, because they don't accept display. We could make that more explicit when talking about the implicit generation.

[tabatkins]

So, uh, your option #4 or #2 seems best. I don't like #1, because it means that element tree shape is only fully determined after the cascade, resulting in (theoretical) nested cascades to assign styles to the newly-created ::marker pseudos.

[Loirooriol]

About #4, I thought that CSS debugging tools that expose the element tree might prefer it to be finite. However, they annoyingly tend to hide tree-abiding pseudo-elements that don't generate boxes, so maybe they don't care.

[Loirooriol]

I have been thinking that the element tree already depends on the cascade because of content.

If you have ::before { content: 'foo'; display: table }, the text foo can't be directly inserted into the box tree as a text run, because it would not be clear into which of the two boxes generated by pseudo-element it should be inserted. Instead, the text should be inserted as a child text node in the element tree, and then CSS Display determines that the generated text run needs to be inserted into the table box.

So if content is able to affect the element tree, I guess display: list-item could too.

[tabatkins]

Discussing with @fantasai, we agree that option 2 is best (::marker always exists, but can only be originated by elements, ::before, and ::after (and future pseudos of similar style)).

Agenda+ for verification from the WG.

[frivoal]

I agree option 2 makes the most sense.

[dbaron]

I would prefer limiting ::marker to elements that have display: list-item. Checking for pseudo-elements can be somewhat expensive, and I'd rather not have to check everything for ::marker all the time.

I don't have a strong opinion on whether ::marker should be attachable to other pseudo-elements that have display: list-item. (I don't think you should be able to make a ::marker display: list-item, and Tab agrees above, so I don't think there's an issue with nesting ::marker once it's restricted to list-item.)

[FremyCompany]

This specification defines a new type of pseudo-element, the ::marker pseudo-element, which is generated by list items to represent the item’s marker (the bullet or number identifying each item).
The ::marker pseudo-element is only created on list items. On any other element, the ::marker pseudo-element’s content property must compute to none, which suppresses its creation.
https://www.w3.org/TR/css-lists-3/#marker-pseudo-element

^ FWIW I'm fine with that, and didn't see a strong reason why we would want to change it.

[FremyCompany]

By the way, @tabatkins argument against 1 doesn't speak much to me because we insert the list-item bullet (or a proxy for it) in the first line box of the list-item to make sure its line-height is big enough to render the marker properly. So, in effect, we already have a requirement to wait for full cascade to entirely determine the tree in Edge and Chrome.

[tabatkins]

Yeah, ::marker is definitely still limited to just list-items; it's suppressed otherwise.