Inlinification happens before run-in fixup, so I don't understand why this is an issue.

@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:

If an inline flow box is inlinified, it recursively inlinifies all of its in-flow children, so that no block-level descendants break up the inline formatting context in which it participates.

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.

@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.

OK, I just thought it could be good to make it clear that run-in layout does not violate this guideline:

Boxes which inlinify their contents can’t directly contain block-level boxes; any boxes generated within such an element must be inline-level.