[css-display][css-flexbox][css-grid] Contradictory definitions of block-level

[Loirooriol]

CSS Flexbox says

flex items themselves are flex-level boxes, not block-level boxes: they participate in their container’s flex formatting context, not in a block formatting context.

Same for CSS Grid:

grid items are grid-level boxes, not block-level boxes: they participate in their container’s grid formatting context, not in a block formatting context.

This seems to mean that participating in a block formatting context is a requirement for being block-level.

However, CSS Display says otherwise:

The keywords specify the element’s outer display type, which is essentially its role in flow layout. They are defined as follows:

• block: The element generates a block-level box.

Then, having a block outer display type is enough to be block-level.

Since flex items and grid items are blockified, they always have a block outer display type. So they are block-level.

This contradicts the first and second quotes.

[SelenIT]

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.

[fantasai]

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

[Loirooriol]

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

[Loirooriol]

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

[SelenIT]

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?

[fantasai]

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

[Loirooriol]

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

[fantasai]

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