[css-display-3] Clarify whether the initial containing block establishes a block formatting context #7207
Description
Empirically, the root element’s box is laid out like a block-level box in a block formatting context. But I can’t find any information in the specs about anything creating the context into which the root element’s box would be laid out.
According to the definition of formatting context in the Glossary, formatting contexts are created by boxes, which implies the initial containing block—being a rectangle, not a box—can’t create one.
So would it be correct to say that the initial containing block establishes a block formatting context for the root element? And that the root element also establishes a new block formatting context, as evidenced by its containment of floats?
And, assuming that the ICB does establish the first block formatting context, is it weird that the root element’s box establishes a new block formatting context even though it “doesn’t have to”?
Activity
Loirooriol commentedon Apr 8, 2022
I guess this is basically #6480
andyjakubowski commentedon Apr 8, 2022
I think it’s tangentially related, but not exactly the same thing.
We know how the root element’s box is laid out. It’s laid out as a block-level box inside the initial containing block. And the CSS WG resolved that the root element is in flow — it’s listed as a change in css-display-3, but not explicitly stated in the body of the spec. I guess technically “A box is in-flow if it is not out-of-flow.” covers it?
We know that:
As far as I was able to determine, there is nothing explicit about the viewport, or the initial containing block establishing a block formatting context.
Of course, we know that’s what actually happens in implementations. But I wonder if it would make sense to clarify it now that you can explicitly establish independent block formatting contexts with
flow-root, as well asflexandgridformatting contexts?Loirooriol commentedon Apr 8, 2022
I wouldn't actually say that the root element participates in a block formatting context. If there was a parent block formatting context, why blockify the root element, or why does it establish an independent BFC with
display: block, or why preventdisplay: contents?It's just roughly considered "block-level" in the sense opposed to inline-level, but not is the strict sense of participating in a BFC. Just like
display: block flowhasblockbut may be flex-level or grid-level depending on the parent.I would say that the root doesn't participate in any formatting context, it just has some special behavior. Or equivalently, that the initial containing block establishes a special root formatting context (but not a BFC) that only accepts a single box. This behavior of the root element could be called root-level.
andyjakubowski commentedon Apr 9, 2022
You’re right, I guess saying that the root element’s box participates in a block formatting context leads to the question of “well, why does the root element’s box establish its own independent block formatting context then?”.
To me, it’s all the more reason to explicitly clarify this in the spec. I think unspecified situations like this make it more difficult to talk about and teach layout to others, especially to people who aren’t aware of how these specs developed over time from having just “normal flow” layout to multiple layout types now.
fantasai commentedon Nov 17, 2022
I think this is worth clarifying. For example, the alignment behavior of the root element is consistent with the way block layout work, but not how flex layout works:
margin: autoaligns in the inline axis, but not in the block axis. That's not otherwise specified, unless we define the IFB to lay out the root element as a block-level box.We could say that the ICB has a special formatting context, but we should define it as a set of differences from block layout; otherwise we'll level various behaviors effectively undefined.
[css-display-3] Define root element term and display type. w3c#7786 w…
fantasai commentedon Nov 18, 2022
OK, I've got a PR for this: #8095
The main open question is: does
floatapply to the root element? It does in WebKit/Blink but not in Gecko. (I think if we have it not apply, it would make the most sense to force-compute it tonone.)p.s. We should take a resolution to republish CR along with this, it's the only change.
Loirooriol commentedon Nov 18, 2022
There are also things like
justify-self. If the root element is block-level, then https://drafts.csswg.org/css-align/#justify-block applies, if it's something special then it's undefined.andyjakubowski commentedon Nov 19, 2022
This looks good to me. Specifying that the root element’s box always establishes an independent formatting context and that the root element’s box is always block-level (ish?) provides the clarification I was looking for. Thank you!
Loirooriol commentedon Nov 19, 2022
Reopening since the change has not landed yet.
fantasai commentedon Dec 6, 2022
Fwiw, I'm leaning towards making
floatcompute tononeon the root. I think this will be an easy change for WebKit/Blink, and will match Gecko and BFO and probably some other implementations that didn't set up full block-level layout for the root.andyjakubowski commentedon Dec 6, 2022
I think this is fine from a user’s point of view, because there’s nothing else to flow around the floated root el’s box.
From the spec’s standpoint, what would we gain by “actively” making
floatcompute tonone? Because this would make the root el’s box special and not just a block-level box in Flow layout, right?bfgeek commentedon Dec 6, 2022
We have precedent elsewhere that
floatshouldn't be forced tononein other contexts which don't support floats (flex/grid/etc) I'd prefer to keep things consistent at let it compute to its value.bfgeek commentedon Dec 6, 2022
Stepping back a bit - is there any reason not to say that the ICB is just a regular block formatting context? E.g. float should work as expected, etc, etc, etc. This matches Blink/WebKit (and likely Firefox modulo float bug). I don't believe Blink has any special ICB logic within block layout.
fantasai commentedon Dec 7, 2022
@bfgeek That's exactly what #8095 does. The question is whether to make
floatcompute tononeon the root element’s principal box, since at least some implementations seem to behave that way.[css-display-3] Define root element term and display type. #7786 #6480 …
fantasai commentedon Dec 7, 2022
Opened up #8196 to discuss whether or not root boxes can float. Closing out the issue now that we've resolved on, and merged, the PR defining ICBs as establishing a BFC. :) Let me know if I missed anything.
[css-display-3] Define root element term and display type. w3c#7786 w…