Repository navigation
[css-display] ::marker is not a box #1625
Description
From Generating Marker Boxes,
The
list-itemkeyword causes the element to generate a::markerpseudo-element box
::marker is a pseudo-element which may generate a box. But it can also generate multiple boxes or no box. I think it should say something like
The
list-itemkeyword creates a::markerpseudo-element which generates boxes as if it were an immediate child of the element
And consider linking CSS Lists Markers, because CSS Pseudo-Elements Markers seems obsolete.
Activity
SelenIT commentedon Jul 20, 2017
Could you please show an example when
::markergenerates multiple boxes? Something likedisplay: list-itemfor the marker itself? By the way, if this is allowed, should that marker of the marker pseudo element be also styleable (with the chain of pseudo elements like::marker::markeror something)?Loirooriol commentedon Jul 20, 2017
I think styling
::markerwith anydisplayvalue which generates multiple boxes in normal elements should do the trick. For example,display: tablegenerates a table wrapper box and a table box. Yes, styling it withlist-itemshould generate a 2nd::markerpseudo-element nested inside the 1st one, this already works with::beforeand::afteron Firefox and Chrome (fiddle) so I don't see why it shouldn't work with::marker.However, I think I read implementations don't want to allow arbitrarily deep structures of pseudo-elements, because that's expensive. So just like you can't insert a
::beforeinside another::before, you can't style a::markerinside a::marker.Loirooriol commentedon Jul 20, 2017
This quote from Introduction should be edited too:
I guess saying this "marker box" concept is a reminiscence from CSS 2.1, which didn't allow to style the
::markerpseudo-element, so it always established a single box. This could still apply with the very limited::markerdefined in CSS Pseudo, but it does not work with the full-fledged::markerdefined in CSS Lists. I'm assuming the last one is the good definition.About the quote in Introduction, I would just use another example. An element can originate a pseudo-element which can generate boxes, so saying that these boxes are originated by the element itself is not entirely wrong. But I would prefer not to say so; otherwise #1604 would worsen, because an element is not supposed to generate more than one principal box.
Instead, the example could mention
display: tablewith its table wrapper box and table box, ordisplay: block rubywith its block container and ruby container.Loirooriol commentedon Jul 22, 2017
After I filed this issue, CSS Lists was edited. Now it says that the whole spec is not ready for implementation and
::markerhas been restricted back to what CSS Pseudo says, properties that affect box characteristics likedisplayare no longer accepted. So if it exists,::markerwill generate a single box, and thus I guess CSS Display may stay as it is. It can also be edited so that if the::markerrestrictions are relaxed in the future (which I hope will happen), the spec will still make sense.tabatkins commentedon Jul 24, 2017
Yeah, I just moved the warning from being manually added to a few sections to being generated by Bikeshed; the spec hadn't been seriously edited for years and wasn't using the newer Bikeshed features.
Yup, Pseudo reflects the current WG consensus on what ::marker should be allowed to do, so I'm just deferring to that. It's basically "what have people actually asked to do with markers", or "what can you currently do to markers by abusing inheritance and wrappers" (setting a style on the list item, then unsetting it on a wrapper around the list-item's contents).
There's no problem with relaxing it in the future, there's just no call for it currently. If you want to do arbitrary things, you have ::before. You can even use
position: markerwith::beforeonce that's implemented, to get it to exactly mimic an outside marker.