[css-display] When are run-in wrapped in anonymous block, exacly?

[Loirooriol]

The Run-In Layout says

2. If a run-in sequence is immediately followed by a block box [...], it is inserted as direct children of the block box [...]. This step recurses if possible [...].
3. Otherwise, an anonymous block box is generated around the run-in sequence and all immediately following inline-level content [...].

My understanding is that if I have

<div style="display: list-item; list-style: inside">
  <span style="display: run-in">Run-in</span>
</div>

then the condition from step 2 does not hold, and thus the "otherwise" from step 3 wraps the run-in inside a block box. So the run-in and the ::marker appear at different lines.

But I'm not sure about this:

<span style="display: run-in">Run-in</span>
<div style="display: list-item; list-style: inside"></div>

The condition from step 2 does hold, and thus the run-in is inserted inside the div after its ::marker, and recursion is attempted. But the condition does no longer hold. Then, does step 3 run or not, i.e. does the "otherwise" refer to the outermost or to the innermost condition in the recursion? If step 3 runs it would be like in the previous example, if it does not the run-in and the ::marker will appear at the same line.

[SelenIT]

IMO, the remaining part of the 2nd bullet point implies that any anonymous fixup doesn't occur after recursion (the formatting step comes immediately after reparenting).

In general, it seems that the spec intents to assure that in any situation the run-in box ends up being the first inline descendant of the block (after ::marker, if it's present and is inline). So the logic is "if there is a block right after run-in, put it there, if not, create it and put it there". But it misses the situation where run-in is already inside a block in the correct position, I suppose there should be one more bullet point before point 2, like "If a run-in sequence is direct children of a block box [...], then do nothing".

So I'd expect both your examples to be rendered in the same line. I don't see any need in anonymous wrapper creation in the first example. Usually, line breaks don't occur in CSS because of literally nothing.

[Loirooriol]

@SelenIT So you would do nothing if the run-in is initially "in the correct position", even if there is a block container after it? I think that would be a bit inconsistent. But run-in layout is weird anyways.

[SelenIT]

Oops, my mistake. Yes, the rule from point 2 should take precedence, check for correct position in the existing block should come after it. So the run-in sequence would always end up in the beginning of the innermost block container, but won't add extra levels of box nesting when it's not necessary.

[Loirooriol]

I think inline-levels should work like this:

1. Run-in sequences are inserted inside the following non-BFC-root block box, if any, with recursion.
2. Non-run-in inline boxes are split by block-level descendants, if any, with recursion. Run-in inline boxes are not split because they inlinify their contents.
3. Inline-level sequences are wrapped inside an anonymous box which establishes an inline formatting context.

An inline-level sequence would be a maximal non-empty sequence of consecutive sibling inline-level boxes or text runs, and intervening out-of-flow boxes.

That is, run-in sequences should not be separated from preceding non-run-in inline-levels. And element-generated block containers should never establish an IFC (#1617).

[tabatkins]

The spec already specifies that "this step recurses", not that the algorithm recurses. The "otherwise" is against the condition that starts step 2, determining which of the two bullet points applies. This is purposely not an ordered sequence of steps (after all, the first bullet point applies to all run-ins, independently of the other two!).

However, we've clarified a bit - we now say "this re-parenting recurses", to not imply that there are ordered steps, and make the "otherwise" more clearly just negating the previous bullet point, rather than sequencing from it.

[Loirooriol]

@tabatkins I still think it's not completely clear, because there will be recursion until the sequence is no longer followed by such a block, and thus it might seem the "otherwise" applies.

It may become more clear if you change the order of these paragraphs.

[fantasai]

@Loirooriol I don't think that is not necessary. a) “Otherwise” is an else-type qualifier, that is, its clause is exclusive with whatever it's contrasting with. If it was additive, we'd use “Then” or “Finally”. b) The "If" and "Otherwise" clauses are in an unordered list, thus, there is not even any implied sequencing.

The reason for keeping the ordering as it is now is that the reparenting aspect of run-ins is what's most important about them, so we want to present that first. Otherwise the text as a whole makes less sense.

[Loirooriol]

I guess it's fine if this is covered by tests to ensure implementers don't get confused.

But just in case, some other less ambiguous ways in my opinion:

Otherwise (if the run-in sequence is not followed by such a block before reparenting)

Otherwise (if the run-in sequence has not been reparented)

[tabatkins]

The current spec already has such a parenthetical (just phrased differently than your suggestions): https://drafts.csswg.org/css-display-3/#run-in-layout

[Loirooriol]

Yes, I meant that in my opinion my suggestions would be an improvement from the current parenthetical.