Repository navigation
[css-display] When are run-in wrapped in anonymous block, exacly? #1640
Description
The Run-In Layout says
- 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 [...].
- 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.
Activity
SelenIT commentedon Jul 21, 2017
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 afterrun-in, put it there, if not, create it and put it there". But it misses the situation whererun-inis 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 commentedon Jul 21, 2017
@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 commentedon Jul 21, 2017
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 commentedon Jul 30, 2017
I think inline-levels should work like this:
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 commentedon Mar 19, 2018
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 commentedon Mar 19, 2018
@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 commentedon Jun 21, 2018
@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 commentedon Jun 21, 2018
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:
tabatkins commentedon Jun 21, 2018
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 commentedon Jun 22, 2018
Yes, I meant that in my opinion my suggestions would be an improvement from the current parenthetical.