I guess this is basically #6480

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:

• The root element’s box is in-flow
• The root element always generates a block-level box, because it gets blockified
• The root element’s box establishes an independent block formatting context, because it contains floats
• When CSS property values of the initial containing block are referenced, they reference the values of the root element (unless otherwise specified, because sometime the body element’s values propagate, too)

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 as flex and grid formatting contexts?

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 prevent display: 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 flow has block but 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.

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.

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: auto aligns 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.

OK, I've got a PR for this: #8095

The main open question is: does float apply 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 to none.)

p.s. We should take a resolution to republish CR along with this, it's the only change.

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.

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!

Reopening since the change has not landed yet.

Fwiw, I'm leaning towards making float compute to none on 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.

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 float compute to none? Because this would make the root el’s box special and not just a block-level box in Flow layout, right?

We have precedent elsewhere that float shouldn't be forced to none in other contexts which don't support floats (flex/grid/etc) I'd prefer to keep things consistent at let it compute to its value.

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.

@bfgeek That's exactly what #8095 does. The question is whether to make float compute to none on the root element’s principal box, since at least some implementations seem to behave that way.

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.