Maybe "its role in flow layout" is the key part here? And the box is block-level only if it participates in flow layout, otherwise its type is defined by the formatting context it is placed in? But I agree, the current wording is confusing and should be clarified.

@SelenIT has it exactly right. I added “in flow layout” to each of the individual definitions to clarify this point, but let me know if you have a better solution.

@fantasai Now it's clear, thanks. But now the effect of the outer display role seems undefined when not in flow layout. I think the spec should say that other layouts are required to either inlinify, blockify or wrap inside a layout-internal box, so that the value is only useful in flow layout.

@fantasai You should also add that "when placed in flow layout" to this quote:

the outer display type, which dictates how the box participates in its parent formatting context.

It says "parent formatting context" in general, not specific to flow layout.

I don't think it's necessary. The same outer display value may dictate different behavior in different formatting contexts (e.g. things like table-row create a bunch of anonymous boxes when placed into the normal flow and just a table row box in the TFC), and this paragraph doesn't aim to list all these rules in details (at least as I read it).

Maybe a new table to briefly summarize what each value does in each type of formatting context would be useful in the same section instead?

@Loirooriol Fixed. It now reads

the outer display type, which dictates how the principal box itself participates in flow layout.

Let me know if that seems to cover it.

@fantasai Yes. But I still think it may be useful to add a note saying that the outer display type has no effect outside of flow layout because others blockify, inlinify or fixup.

@Loirooriol Given how recently the scope of what other layout models do was wide open for exploration, I'd rather not have Display explain what other layout models (that it does not define) do.