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.

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.

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.

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.

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.

I agree option 2 makes the most sense.

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.)

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.

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.

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

The Working Group just discussed Is ::marker created by display:list-item or does it always exist?, and agreed to the following resolutions:

• RESOLVED: marker exists on all elements, on ::before and on ::after but no box unless it's display: list-item

I believe this is now edited into css-lists-3. Let me know if css-pseudo-4 needs additional clarifications? @Loirooriol @FremyCompany @tabatkins

@fantasai I don't see this in css-lists-3, where does it say for instance that ::marker cannot have a nested ::marker?

@fantasai I think https://drafts.csswg.org/css-lists/#list-item could clarify that ::before and ::after can also be list items.

@Loirooriol Added a note about the existence of ::before::marker and ::after::marker

@FremyCompany ::marker cannot accept display in this level, so ::marker::marker cannot have an effect. We do need to clarify

• If ::marker::marker is invalid.
• If in the future we allow display to apply, do we force it to compute list-item to flow?

• I'm ambivalent about whether ::marker::marker is invalid. I'm inclined to say it's "valid but never matches anything", but I can easily go either way.

• Yes, we should explicitly prevent ::marker from having display: list-item in the future; computing it to flow makes sense to me. There is no reasonable use-case for making the marker of a list item be a list item. ^_^

If ::marker::marker is invalid.

That's what Chromium does, if you enable experimental flags, the parser accepts ::before::marker and ::after::marker but ::marker::marker is invalid (https://wpt.fyi/results/css/css-pseudo/parsing/tree-abiding-pseudo-elements.html).

If in the future we allow display to apply, do we force it to compute list-item to flow?

Seems reasonable. Or more precisely, I would just remove list-item from the computed value. So flow-root list-item would become flow-root, not flow.

The CSS Working Group just discussed Existence of ::marker::marker, and agreed to the following:

• RESOLVED: ::marker::marker is invalid
• RESOLVED: accept proposal above