Repository navigation
[css-display][css-pseudo] Is ::marker created by display:list-item or does it always exist? #1793
Description
::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:
::markerpseudo-elements are only created whendisplayhas thelist-itemkeyword.::markeralways exist but are only originated by elements,::before, and::after. They can't be originated by other::marker.::markeralways exist but are only originated by elements. Like::beforeand::after, they can't be originated by other pseudo-elements. This would be a breaking change for Firefox and Chrome.::markeralways 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.
Activity
tabatkins commentedon Sep 11, 2017
Ah, I was inclined to say they always exist (but only generate boxes when
display:list-itemon 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,
::markerpseudos can't ever generate meaningfully generate more::markers, because they don't acceptdisplay. We could make that more explicit when talking about the implicit generation.tabatkins commentedon Sep 11, 2017
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 commentedon Sep 11, 2017
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 commentedon Sep 15, 2017
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
contentis able to affect the element tree, I guessdisplay: list-itemcould too.tabatkins commentedon Mar 19, 2018
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 commentedon Mar 20, 2018
I agree option 2 makes the most sense.
dbaron commentedon Mar 20, 2018
I would prefer limiting
::markerto elements that havedisplay: list-item. Checking for pseudo-elements can be somewhat expensive, and I'd rather not have to check everything for::markerall the time.I don't have a strong opinion on whether
::markershould be attachable to other pseudo-elements that havedisplay: list-item. (I don't think you should be able to make a::markerdisplay: list-item, and Tab agrees above, so I don't think there's an issue with nesting::markeronce it's restricted tolist-item.)FremyCompany commentedon Mar 23, 2018
^ FWIW I'm fine with that, and didn't see a strong reason why we would want to change it.
FremyCompany commentedon Mar 23, 2018
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 commentedon Mar 23, 2018
Yeah, ::marker is definitely still limited to just list-items; it's suppressed otherwise.
css-meeting-bot commentedon Apr 12, 2018
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-itemThe full IRC log of that discussion
<dael> Topic: Is ::marker created by display:list-item or does it always exist?<dael> github: https://github.com//issues/1793
<dael> 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.
<dael> TabAtkins: We wanted approval that marker elements always existing hte box tree on eleemnts before or after and they're auto surpressed.
<dael> 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.
<dael> 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.
<dael> TabAtkins: Depends on the theoretical model you want.
<dael> emilio: Is that required? Except for slotted I think most browsers reject pseudo elements at parsing time.
<dael> TabAtkins: Does not require that.
<dael> TabAtkins: That would be good if you actual style mested marker.
<dael> emilio: It would mean you can set content-before.
<dael> TabAtkins: Ideally you should be able to, but right now you have an unstylable marker.
<dael> dbaron: Auto-surpressed?
<dael> 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.
<dael> dbaron: Is there a distinction between exists and surpressed and not existing?
<dael> 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.
<dael> TabAtkins: We suggest they always exist on elements, ::before and ::after
<dael> fremy: is that all browsers do?
<dael> TabAtkins: THose are all that browsers have always there. If we add more we can categorize properly.
<dael> TabAtkins: Objections to my preferred option that marker exists on all elements, on ::before and on ::after but no box unless it's displayed.
<dbaron> s/displayed/display: list-item/
<dael> 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?
<dael> TabAtkins: It does not show up.
<dael> Rossen: Obj?
<dbaron> sounds good to me
<dael> RESOLVED: marker exists on all elements, on ::before and on ::after but no box unless it's display: list-item
11 remaining items
tabatkins commentedon Oct 23, 2020
I'm ambivalent about whether
::marker::markeris 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
::markerfrom havingdisplay: list-itemin the future; computing it toflowmakes sense to me. There is no reasonable use-case for making the marker of a list item be a list item. ^_^Loirooriol commentedon Oct 23, 2020
That's what Chromium does, if you enable experimental flags, the parser accepts
::before::markerand::after::markerbut::marker::markeris invalid (https://wpt.fyi/results/css/css-pseudo/parsing/tree-abiding-pseudo-elements.html).Seems reasonable. Or more precisely, I would just remove
list-itemfrom the computed value. Soflow-root list-itemwould becomeflow-root, notflow.css-meeting-bot commentedon Oct 23, 2020
The CSS Working Group just discussed
Existence of ::marker::marker, and agreed to the following:RESOLVED: ::marker::marker is invalidRESOLVED: accept proposal aboveThe full IRC log of that discussion
<fantasai> Topic: Existence of ::marker::marker<fantasai> github: https://github.com//issues/1793
<fantasai> https://github.com//issues/1793#issuecomment-708072107
<RRSAgent> I have made the request to generate https://www.w3.org/2020/10/23-css-minutes.html fantasai
<florian_irc> scribenick: Florian
<florian_irc> fantasai: This is a follow to previous decisions on ::marker
<florian_irc> fantasai: we didn't want to have infinite markers
<florian_irc> fantasai: so you cannot have ::marker::marker
<florian_irc> fantasai: right now ::marker doesn't accept the display property
<florian_irc> fantasai: so, is ::marker::marker invalid?
<florian_irc> fantasai: and, in the future, if we want to allow that
<fantasai> s/that/display on ::marker/
<florian_irc> fantasai: then, do we force it to compute display so that it loses its list item
<florian_irc> Rossen_: so, taking things one at a time, should we allow ::marker::marker
<florian_irc> fantasai: I'd like to make it invalid
<florian_irc> TabAtkins: browsers don't support it
<tantek> +1 on no ::marker::marker
<florian_irc> oriol: implementations are behind flags, so not too relevant
<florian_irc> oriol: in firefox, no nested pseudos
<florian_irc> oriol: in chrome ::before::marker and ::after::marker work, but ::marker::marker doesn't
<florian_irc> oriol: but then the styles don't quite work anyway
<florian_irc> oriol: so I'd prefer to keep it invalid
<florian_irc> Rossen_: any objection to ::marker::marker being invalid
<florian_irc> RESOLVED: ::marker::marker is invalid
<florian_irc> fantasai: in the future, when display applies to ::marker, should it lose the list itemness
<florian_irc> oriol: seems reasonable
<florian_irc> Rossen_: me too
<florian_irc> RESOLVED: accept proposal above
<TabAtkins> ScribeNick: TabAtkins
[css-pseudo-4] Specify ::marker::marker as invalid, define that displ…