[css-lists] [css-pseudo] need to define blockification of outside markers / interaction of display: inline list-item with list-style-position

[emilio]

Outside markers are defined to create block containers. This is as of today implemented in both Gecko and Blink at least as a computed-style-time hack:

• Gecko.
• Blink.

Right now that has a visible effect via getComputedStyle(element, "::marker").display (this test tests for it).

However:

• The spec should probably say how it is implemented given it is observable.
• That is not quite sound with display: inline list-item, because the display value may be ignored / overridden.

The last bullet point is, of course, if we agree that display: inline list-item ignores list-style-position (which Gecko does right now), but it seems a bit under-defined.

So in Gecko, I'm going to change this to be a used-value-time blockification (mostly to prevent the case where we have a block element like <details> with display: inline list-item and fail to blockify the marker). But I'm happy to adapt to whatever solution we end up with here since we're the only ones implementing inline list-item after all.

cc @Loirooriol @MatsPalmgren @jfkthame

[Loirooriol]

if we agree that display: inline list-item ignores list-style-position

I agree, and https://drafts.csswg.org/css-lists/#list-style-position-property already says

If the list item is an inline box: this value is equivalent to inside.

Why do you want to do it at used-value time? Blockifications happen at computed-value time in other cases, so it seems inconsistent.

mostly to prevent the case where we have a block element like <details> with display: inline list-item and fail to blockify the marker

But I don't think it should be blockified in that case, because list-style-position: outside will behave as inside?

OK, I see that in Firefox the marker is still outside in <details style="display: inline list-item; list-style-position: outside;"> even though it produces an inline box. Why?

[emilio]

Why do you want to do it at used-value time? Blockifications happen at computed-value time in other cases, so it seems inconsistent.

Not always, for cases where the blockification can't happen at computed-value time. For example, for a rendered <legend> element of a <fieldset>, Firefox blockifies at used-value time, because you can't determine whether you're a rendered legend at computed-value time.

There's more background in whatwg/html#6310 (and I'd be ok to change this to match Blink tbh, which always blockifies all <legend> elements, but @MatsPalmgren didn't seem pretty on-board with that).

OK, I see that in Firefox the marker is still outside in <details style="display: inline list-item; list-style-position: outside;"> even though it produces an inline box. Why?

Because <details> ignores display and creates a block container per spec.

[Loirooriol]

Resolving at used-value time seem unnecessary complex to me. I think I would rather prefer to just force the marker to be inside if you use display: inline list-item, even if it ends up generating a block container rather than an inline box.

I think this is somewhat analogous to #4065: if you use display: grid or flex, the children will be blockified, even if you actually get a block container rather than a grid/flex container.

In Chromium, ::marker currently gets a different computed style depending on whether its inside or outside, so I would prefer to know its position at computed-value time, not used-value time.

[emilio]

Resolving at used-value time seem unnecessary complex to me. I think I would rather prefer to just force the marker to be inside if you use display: inline list-item, even if it ends up generating a block container rather than an inline box.

Yes, that is a separate option (and why I opened that issue). Do you mean forcing the marker to be inside at used value time (without checking list-style-position), or forcing the computed value of list-style-position to be inside if the display is inline list-item? The later might be the simplest way to implement it, but it seems a bit weird because list-style-position is inherited so it affects all the descendants.

[Loirooriol]

Yeah, changing the computed value of list-style-position seems bad for inheritance. Chromium has a quirk that a li::marker with no ol or ul ancestor is forced to be inside, but this doesn't affect the computed value of the li for this same reason.

So I guess we could say that list-style-position is changed at used-value time, but this is known by the ::marker at computed value time? Or that a computed display: inline list-item directly forces the ::marker to be inside at computed-value time without changing list-style-position?

I guess the potential problem of using the computed display and not the actual box is that a display: list-item might theoretically be forced to generate an inline box. So we would have an outside ::marker in an inline list item box, which we want to avoid... But I don't think that being forced to generate an inline box is possible for now.