Repository navigation
[css-display] run-in fixup should create inline-block when parent inlinifies #1607
Description
This is like #1590 but for run-in instead of tables. CSS Display says
an anonymous block box is generated around the run-in sequence
But I guess this block box should be an inline-level block container if the parent inlinifies, e.g. inside internal ruby boxes or inside another run-in with a flow inner display type. Maybe it would be better to be consistent with table fixup and also generate an inline-block inside non-run-in inline boxes.
Alternatively, in these cases the wrapper could be an inline box, or generate no wrapper.
Activity
fantasai commentedon Mar 19, 2018
Inlinification happens before run-in fixup, so I don't understand why this is an issue.
Loirooriol commentedon Mar 19, 2018
@fantasai So the problem is that inlinification happens first, then run-in fixup creates a block box, and then you end up with a block box inside a ruby or an inline run-in, which do not tolerate block boxes inside them. It's a violation of this principle:
Loirooriol commentedon May 8, 2018
Well, I guess this is not really a problem right now, because if an ancestor inlinifies, the run-in will become a normal inline.
But I can image some future spec that makes some block boxes inlinify their contents without establishing a BFC. Then, one could have a run-in just before such a block, the run-in wouldn't be inlinified, it would be reparented inside the block, and then generate an anonymous block. But the element-generated block inlinifies its contents, so it doesn't tolerate the anonymous block child.
fantasai commentedon Jun 21, 2018
@Loirooriol That seems like a very hypothetical situation and I can't even imagine why it would occur. If it does, though, we can adjust all the specs as necessary--they are not frozen for all time, just stabilized under current conditions.
Loirooriol commentedon Jun 21, 2018
OK, I just thought it could be good to make it clear that run-in layout does not violate this guideline: