Definition of "Block-level box" in CSS2 Specification

[gitspeaks]

Context:

The CSS2 specification at section 9.4.1 "Block Formatting Contexts" references the term "block boxes" and implies conditions under which a block formatting context is established. The definition states:

"Floats, absolutely positioned elements, block containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts for their contents."
See Section 9.4.1

In Section 9.2.1, “block boxes” are defined as follows:

"Block-level boxes that are also block containers are called block boxes."
See Section 9.2.1

Clarification Needed:

1. Circular Definition of "Block-level box":

   • Section 9.2.1 states that "Block-level boxes are boxes that participate in a block formatting context," which implies that the status of being a "block-level box" depends on an ancestor's formatting context.

   • However, if a block box (e.g. a block-level box) establishes a new block formatting context, it raises a potential circular definition: is a box’s participation in a block formatting context both a cause and an effect of being a "block-level box"? In other words, which comes first: being a "block-level box" or participating in a block formatting context?

   • Additionally, what happens to the principal block-level box of a block-level element if that element is referenced within an inline formatting context? Does it still maintain the properties of a block-level box in this case, or is its block-level status altered by its context within the inline formatting context

2. Block-level Boxes as Block Containers:

   • The specification states: "a block-level box is also a block container box," but further states that "Block-level boxes that are also block containers are called block boxes."

   • The use of "also" suggests that there could be "block-level boxes" that are not "block containers," which contradicts the earlier statement that block-level boxes are inherently block containers. Could clarification be provided on whether "block-level boxes" are always "block containers," or only in certain contexts (e.g., only when containing descendants)?

3. Is it correct to assume that a principal block-level box implicitly establishes a block formatting context, even in the absence of specific formatting context triggers (like float or absolute positioning)?

Thanks in advance!

[Loirooriol]

CSS2 isn't superclear about these concepts, you should check https://drafts.csswg.org/css-display-4/#glossary instead.

implies that the status of being a "block-level box" depends on an ancestor's formatting context

Yes.

which comes first: being a "block-level box" or participating in a block formatting context?

Nothing comes first, that's just a definition.
We say that a box is block-level if it participates in block layout, flex-level if it participates in flex layout, etc.

Additionally, what happens to the principal block-level box of a block-level element if that element is referenced within an inline formatting context?

You can't have a block-level box in an inline formatting context. If the outer display type is block, then the box splits the inline formatting context, as explained in https://drafts.csswg.org/css2/#anonymous-block-level

a block-level box is also a block container box

This is not a definition, it's a consequence of CSS2 having a more limited number of layouts. And you omitted "Except for table boxes", which nowadays also includes other things like flex and grid containers.

The use of "also" suggests that there could be "block-level boxes" that are not "block containers,"

Yes, in CSS2, table boxes are block-level but not block containers.

which contradicts the earlier statement that block-level boxes are inherently block containers

No.

Is it correct to assume that a principal block-level box implicitly establishes a block formatting context, even in the absence of specific formatting context triggers (like float or absolute positioning)

No. A block-level box can only establish a block formatting context if its a block container (e.g. if it's a flex container it will establish a flex formatting context). But block boxes default to continuing the parent formatting context rather than establishing an independent one.

[gitspeaks]

CSS2 isn't super clear about these concepts; you should check https://drafts.csswg.org/css-display-4/#glossary instead.

Thank you for the suggestion. I did consult this glossary, but it ultimately references the same sections in the CSS2 specification that I detailed in my initial post.

From Appendix A: Glossary:

"block-level - Content that participates in block layout. Specifically, block-level boxes."

"block layout - The layout of block-level boxes, performed within a block formatting context."

"block container
A block container either contains only inline-level boxes participating in an inline formatting context, or contains only block-level boxes participating in a block formatting context (possibly generating anonymous block boxes to ensure this constraint, as defined in CSS2§9.2.1.1). "

block formatting context
inline formatting context
Block and inline formatting contexts are defined in CSS 2.1 Section 9.4. Inline formatting contexts exist within (are part of their containing) block formatting contexts; for example, line boxes belonging to the inline formatting context interact with floats belonging to the block formatting context.

The circularity of these definitions remains an issue: CSS 2.1 Section 9.4 defines "block formatting context" in terms of "block containers" and "block boxes," which are themselves defined by "block formatting context."

In particular, I’m having trouble understanding the following:

1. When and where a block formatting context begins and ends

2. How does the "block formatting context" interact with "block-level boxes" and "block containers"?

3. If the status of being a "block-level box" depends on an ancestor's formatting context, who or what serves as the initial ancestor? Is there a type of "root" block container or block-level box that exists outside any other formatting context?

[Loirooriol]

When and where a block formatting context begins and ends

A block formatting context is established by a block container which isn't block-level (so there is no parent block formatting context to continue), or that is forced to establish an independent formatting context.

This block formatting context lays out the contents of the block container, but if some content establishes an independent formatting context, then the nested contents will be laid out with that other formatting context.

How does the "block formatting context" interact with "block-level boxes" and "block containers"?

Block containers can establish a block formatting context or continue the block formatting context from the parent. Regardless of that, it can also establish an inline formatting context.

A block container can only contain block-level contents or, if it establishes an inline formatting context, it can only contain inline-level contents.

Block containers can be block-level, inline-level, flex-level, out-of-flow, etc.

Is there a type of "root" block container or block-level box that exists outside any other formatting context?

See #8095

[gitspeaks]

Is it correct to say that a "block-level box" becomes a "block container" when it contains only "block-level boxes" as direct children? In this case, it is said to either establish a new "block formatting context" or continue the "block formatting" context from the parent. Similarly, does a "block-level box" become a "block container" if it contains only "inline-level boxes" as direct children, thereby establishing an "inline formatting context" ?

[Loirooriol]

No, that's backwards. Being a block container depends on the inner display type, not on the contents. The in-flow contents being block-level or inline-level is a consequence of being a block container. And being a block container is unrelated to being block-level, you can have inline-level block containers (a.k.a inline-block).

[gitspeaks]

You mentioned:

A block formatting context is established by a block container which isn't block-level (so there is no parent block formatting context to continue), or that is forced to establish an independent formatting context.

This block formatting context lays out the contents of the block container, but if some content establishes an independent formatting context, then the nested contents will be laid out with that other formatting context.

However, referring to #8095, it states:

"defining the ICB to establish a block formatting context so that the root element's box is fully defined to be a block-level box"

According to the glossary, the ICB isn’t classified as a block container; it’s described as a “rectangle” rather than a “box,” so this may be an edge case. However, this statement seems to suggest that creating a block formatting context within the ICB is essential for the root element’s principal box to function as a block-level box.

This is somewhat confusing because as I understand a BFC doesn’t enforce block-level behavior on its descendants. A BFC can contain both block-level and inline-level elements.

Could you please clarify how the BFC established by the ICB specifically ensures that the root element’s box behaves as a block-level box, given that a BFC generally doesn’t impose block-level constraints on its children?

[Loirooriol]

• the ICB isn’t classified as a block container; it’s described as a “rectangle” rather than a “box,”

  Yeah. But there is typically some abuse of notation when referring to containing blocks, or maybe formatting contexts can be established by either a box or the initial containg block. Feel free to file an issue about this.

• how the BFC established by the ICB specifically ensures that the root element’s box behaves as a block-level box

  This doesn't happen automatically, it's explicitly forced in https://drafts.csswg.org/css-display/#root

  The root element’s display type is always blockified

[gitspeaks]

This doesn't happen automatically, it's explicitly forced in https://drafts.csswg.org/css-display/#root
The root element’s display type is always blockified

It seems that the root element being block-level is a direct definition achieved through blockification, not a consequence of the ICB establishing a block formatting context. Would you consider rephrasing the statement in #8095

"defining the ICB to establish a block formatting context so that the root element's box is fully defined to be a block-level box"

to clarify that the root element is defined as block-level through blockification, independent of the BFC established by the ICB? This might help make the relationship clearer.

[Loirooriol]

That sentence isn't in the spec, the spec already mentions blockification.

Also I don't think it matters much whether the root element participates in a special kind of block formatting context with some extra behavior like blockifying contents, or whether the blockification is unrelated to the formatting context.

[gitspeaks]

It seems like the main idea here is that, because a block formatting context (BFC) restricts its content to block-level elements, the root element box naturally has to be a block-level box. But this raises a bigger question: what happens to elements with an inline outer display within a BFC? The spec mentions creating anonymous block boxes around inline content, like 'Some text,' but it doesn’t really clarify what effect a BFC has on inline elements when they’re mixed in with block-level siblings. If the BFC actually applied some kind of transformation to its content, this behavior might make a bit more sense.

[Loirooriol]

a block formatting context (BFC) restricts its content to block-level elements

Well, the current spec allows for a BFC to be established simultaneously with an inline FC, so there is no such restriction.

Though in the past I have argued that inline FCs should only be established by anonymous block containers that are generated around sequences of inline-level contents (so an anonymous block box would still need to be generated even for non-anonymous block containers that only have inline-level contents). This would prevent the simultaneous FC situation, and would imply that a BFC can only have block-level contents (but this still wouldn't explain the blockification of the root).

it doesn’t really clarify what effect a BFC has on inline elements when they’re mixed in with block-level siblings

I think it's clear from the spec that they are placed inside anonymous block boxes as you say, and then these establish an inline formatting context.
A BFC doesn't blockify its contents in general.