[css-lists] Are outside markers out-of-flow?

[Loirooriol]

The spec used to explain outside markers using position: marker, which counted as absolutely positioned, and thus out-of-flow.

Then position: marker was removed, and in #3771 @MatsPalmgren claims that abspos may not be web compatible. But maybe we can agree on whether they are out-of-flow or not?

This matters for example when propagating text decorations:

the decorations are propagated to all in-flow children

Consider this testcase:

<a href="">
  <div>item</div>
  <div>item</div>
  <div>item</div>
</a>

div { display: list-item; margin-left: 40px; white-space: pre }
div:nth-child(1) { list-style-type: decimal }
div:nth-child(2) { list-style-type: "1. " }
div:nth-child(3)::marker { content: "1. " }

Firefox	Chromium LayoutNG	Chromium legacy

Should the markers be underlined or not? I think taking them out-of-flow (and thus not underlining them) looks better. I guess they could then be painted at step 5 with "non-positioned floating descendants" https://drafts.csswg.org/css2/zindex.html#painting-order

[Loirooriol]

In https://crrev.com/506884 @kojiishi said:

Out-of-flow position looks more reasonable, but crbug.com/734554 is blocking.

[tabatkins]

Yes, I think they should be out-of-flow. They act, layout-wise, like an out-of-flow box.

[MatsPalmgren]

No, they can't be out-of-flow. That wouldn't be web-compatible. I explained all this in #3771, please read it.

[Loirooriol]

@MatsPalmgren You explained that markers can't be abspos. Non-positioned out-of-flows are painted more similar to in-flows. So I was wondering if this could be web-compatible.

Anyways, even if not backwards-compatible in some cases, would changing it really break websites?

[MatsPalmgren]

Introducing a new kind of out-of-flow is a fairly invasive change though. So I think there needs to be strong arguments for doing that.

So let's examine your use case again. The argument is that not underlining outside markers "looks better". But if you click the marker in your example it actually navigates, so I think removing the underline also removes semantic value for users (namely that it's part of the link). I'm not sure I agree that aesthetics should trump semantics here. And if you think that it should, then why only outside markers? Surely inside markers would also look better without an underline, right? But then the whole argument for making outside markers out-of-flow for this reason falls. I think that if we want to support this use case then we should address it directly with something like text-decoration-skip: markers to let authors decide. (In general, choices about aesthetics shouldn't be built-in in a way that authors can't override.)

Putting list items inside a link also seems like a rare use case. I'm guessing text-decoration: line-through is probably more common, e.g. to indicate that part of a document is obsolete/deleted or whatever. In this case, it would feel wrong to me to not apply the text-decoration to the markers.

It's also worth noting that outside markers influence the first line's line-box size so it's not really out-of-flow in the sense that it doesn't affect the in-flow size either.

And as I said before, I'm opposed to changing the painting order in any way from what browsers are currently doing. It's a very risky change to make from web-compat perspective and there's nothing to be gained by it. (That said, we could simply spec that they paint with in-flow boxes as before even if we decide to call them out-of-flow for other reasons.)

So far, I remain unconvinced that making outside markers out-of-flow is a good idea. I think the arguments for keeping them in-flow are stronger.

[Loirooriol]

In Chromium LayoutNG, outside markers are implemented as inline-blocks, and text decorations are not supposed to be propagated to atomic inlines. So doing that seemed a bug, which has been fixed as a side-effect of my work for implementing ::marker.

Decoration propagations for outside markers are mostly interoperable now, but not for inside ones. Testcase

Firefox	Chromium LayoutNG	Chromium legacy	WebKit	Edge

It's also worth noting that outside markers influence the first line's line-box

This is a MAY in the spec. For example Firefox doesn't seem to always do it, so outside markers can seem out-of-flowish. But Chromium does it, so that's a convincing argument against out-of-flow.

[emilio]

I think conceptually firefox applies the decorations all the time, but we don't apply it to legacy list markers because they have an special painting path.

[MatsPalmgren]

Right, it was an accident when I implemented ::marker that it applies text decorations. I'm currently removing our legacy rendering path for list-style-type/image markers and instead creating generated content and making it take the same path as ::marker { content: ...}. I'll address this at the same time to make all markers have the same (old) behavior.

That said, I'm willing to decorate inside markers by default as suggested if we add display to the list of supported ::marker properties to enable authors to opt out from decorations with ::marker { display: inline-block } or some such. We should give authors the tools they need to workaround this backwards-incompatible change. As I've said before, there's no reason to tie authors' hands behind their back with these unmotivated restrictions on ::marker anyway. It literally goes through the same box construction, layout and rendering paths as ::before/::after which doesn't have these property restrictions. (Granted, there's some special sauce to position an outside marker and make it influence the primary box block-size, but that doesn't really motivate these restrictions either. We can sort that out separately in #3771). Giving authors explicit control over what's included/excluded from decoration, either via a new property, or a new value on an existing property (like text-decoration-skip) also works.

The table of results above is incomplete though. It appears Chrome (both legacy and LayoutNG) never underlines list-style-type:disc etc. It also handles <li> without a parent <ol>/<ul> differently (it underlines outside markers): testcase.

I tend to think that all types (images excluded obviously) of inside markers should behave the same w.r.t decorations. Outside markers too, whether they have a <ol>/<ul> parent or not.

[Loirooriol]

Chrome (both legacy and LayoutNG) never underlines list-style-type:disc etc.

That's because symbol markers are painted specially, it's not actual text (e.g. you still see a disc with font-family: Ahem, and text-shadow has no effect).

It also handles <li> without a parent <ol>/<ul> differently

That's because in that case there's a quirk that forces the marker to be inside.

It literally goes through the same box construction, layout and rendering paths as ::before/::after

Not in Chromium, it has special layout classes for markers. 5 classes, and adding inline-block inside markers would require 2 extra classes, or maybe refactor them as a mixin or something. Also, if we allow display, it's not clear how things like grid, table, ruby, etc. would behave with outside markers.