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

[css-meeting-bot]

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

The full IRC log of that discussion

Topic: Is ::marker created by display:list-item or does it always exist?
github: https://github.com//issues/1793
TabAtkins: We all agree on overall behavior. More a question what model we want. Marker pseudo element. Original question is decided. It was what things in theory can have marker pseudo elements. It's only created by thing with display list item. Theoretical model of the element tree, which things have the display list item.
TabAtkins: We wanted approval that marker elements always existing hte box tree on eleemnts before or after and they're auto surpressed.
TabAtkins: Other options are if they exist in the tree depends on style or say they always exist but not on elements but not on pseudo elements ::before or ::After which breaks the current behavior for FF and Chrome.
TabAtkins: Final option is marker elements always exist and can be on any tree abiding elements. This could mean that market pseudos contain marker pseudos. Because you can't set display on them you'll never see them.
TabAtkins: Depends on the theoretical model you want.
emilio: Is that required? Except for slotted I think most browsers reject pseudo elements at parsing time.
TabAtkins: Does not require that.
TabAtkins: That would be good if you actual style mested marker.
emilio: It would mean you can set content-before.
TabAtkins: Ideally you should be able to, but right now you have an unstylable marker.
dbaron: Auto-surpressed?
TabAtkins: Like how ::before doesn't create a box unless it's non-none. Marker wouldn't have a box unless it's contents had display.
dbaron: Is there a distinction between exists and surpressed and not existing?
TabAtkins: One is a layer violation. It requires us to not completely build on the tree until we resolve the styles. Right now we can build the element tree fully. This is theoretical design and has no practical considerations.
TabAtkins: We suggest they always exist on elements, ::before and ::after
fremy: is that all browsers do?
TabAtkins: THose are all that browsers have always there. If we add more we can categorize properly.
TabAtkins: Objections to my preferred option that marker exists on all elements, on ::before and on ::after but no box unless it's displayed.
s/displayed/display: list-item/
florian: If you display list-item...the initial value of content is normal then you get it but if you don't display list item is it like a ::before?
TabAtkins: It does not show up.
Rossen: Obj?
sounds good to me
RESOLVED: marker exists on all elements, on ::before and on ::after but no box unless it's display: list-item

[fantasai]

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

[FremyCompany]

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

[Loirooriol]

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

[fantasai]

@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?

[tabatkins]

• 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. ^_^

[Loirooriol]

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.

[css-meeting-bot]

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

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

The full IRC log of that discussion

Topic: Existence of ::marker::marker
github: https://github.com//issues/1793
https://github.com//issues/1793#issuecomment-708072107
I have made the request to generate https://www.w3.org/2020/10/23-css-minutes.html fantasai
scribenick: Florian
fantasai: This is a follow to previous decisions on ::marker
fantasai: we didn't want to have infinite markers
fantasai: so you cannot have ::marker::marker
fantasai: right now ::marker doesn't accept the display property
fantasai: so, is ::marker::marker invalid?
fantasai: and, in the future, if we want to allow that
s/that/display on ::marker/
fantasai: then, do we force it to compute display so that it loses its list item
Rossen_: so, taking things one at a time, should we allow ::marker::marker
fantasai: I'd like to make it invalid
TabAtkins: browsers don't support it
+1 on no ::marker::marker
oriol: implementations are behind flags, so not too relevant
oriol: in firefox, no nested pseudos
oriol: in chrome ::before::marker and ::after::marker work, but ::marker::marker doesn't
oriol: but then the styles don't quite work anyway
oriol: so I'd prefer to keep it invalid
Rossen_: any objection to ::marker::marker being invalid
RESOLVED: ::marker::marker is invalid
fantasai: in the future, when display applies to ::marker, should it lose the list itemness
oriol: seems reasonable
Rossen_: me too
RESOLVED: accept proposal above
ScribeNick: TabAtkins