+1 to making the name be more explicit about the effect, though tying it to 'float' might also be confusing. Container seems appropriate. Are there terms in common use by web devs that correlate to 'block formatting context'?

I fear the term most in common use might be hasLayout, but I don't think we want that one, and I don't think it exactly matches the concept of block formatting context.

@smfr, CSS also uses the term "normal flow", as opposed to other positioning schemes. I believe that the term "flow root" comes from that meaning of "flow" (also mentioned in the block formatting section), maybe with some influence of the "sectioning root" concept from HTML5.

AFAIK, there are at least three aspects in which BFC-establishing elements differ from regular blocks:

1. Containing nested floats (most often mentioned)
2. Collapsing margins
3. Border box overlapping with floats (paragraph above the "Example" in Section 9.5 of CSS2.2)

If display:flow-root affects all of these, I suppose that naming should also reflect them all.

Note that this has already been implemented in Firefox and Chrome, and, if I'm not wrong, it'd be shipped in Firefox 53 and Chrome 57.
So, if we want to change the name it should be fast enough so it's not shipped with a different syntax.

I don't see much need in renaming. Are authors really more familiar with Regions (which the Chrome team even doesn't plan to support) than with phrases like "absolutely positioned elements are removed from the flow" (often used in many CSS articles for beginners) or with the "Flow content" concept from HTML5? Existing implementations also count against the renaming, IMHO.

But if the renaming is absolutely necessary, I suppose it's important to highlight that the BFC-establishing element is 'self-contained', that nothing inside it overlaps anything outside it (leaving out special cases like negative margins). What about display: enclosed-block, or separate-block, or just new-block (since it establishes the new BFC)?

Right; the term "out-of-flow" shows up plenty in specs; anyone who looks at layout specs or tutorials that use similar wording will have at least some exposure to the term.

(fantasai and I used the "flow" terminology for the two keywords because we needed some term that covered both "block" and "inline" stuff, and "flow" was already threaded thruout the specs to refer to that layout mode's concepts.)

It's not just about containing floats... or even just about blocks. The 'flow' keyword (as opposed to 'flow-root') is applied to blocks to indicate that their context and their contents are all part of the same formatting context--implying a certain boundary transparency wrt margins and floats--but it also is applied to inlines to indicate the same thing, that the contents of the inline and its surrounding context all participate in the same formatting context (which in this case is about merging text runs, aligning together, performing bidi-reordering across boundaries, etc.).

"Flow" is also used to describe the content model in HTML that allows intermixing of block and inline content, and we wanted to tie into that concept.

If the name is left as-is, the rationale for the name from @fantasai might well be worth including in the spec. It was usefully illuminating for me and might be for many others too.

I propose "display: river", because there's a flow, and elements can float. To metaphorical maybe?

@nadangergeo, as for me, "display:river" fits better for display:flow (as a metaphor of the open stream of water that can carry floating things far away), flow-root is more like "display:lake" (as something completely enclosed by its banks that floating things never escape). But I'm afraid it's still too metaphorical and there is no other concept in CSS that would support this metaphor:)

There is nothing wrong with the flow-root keyword, it is quite clear and natural based on what it does.

Fwiw, if renaming was required, isolated or context would probably be viable options.

Considering display: flow - and how I understand it should work - would display: flow-block instead of display: flow-root make sense?

Just from the nomenclature it would also be in line with display: block vs display: inline-block in a way.

As an old-school CSSer, I read the description and thought it was effectively "block" but containing floats. How about block-container.

Slightly related, does it have to be on display? Could it apply to flex or grid as well? If so, perhaps a separate attribute would be more effective?

Based on the description in the spec,

The element generates a block container box, and lays out its contents using flow layout. It always establishes a new block formatting context for its contents.

I like the "flow-block" suggestion by @inoas

There is a problem with "flow-block" suggestion: there is already a display: block flow longhand value in the spec, which means just the opposite — the block that doesn't establish new block formatting context (i.e., default display:block behavior). Would be way more confusing that the current naming.

If I understand correctly, the whole flow/flow-root thing that @fantasai explains in #964 (comment) applies only to blocks and inlines (collectively referred as "flow layout") since they are the only two display values that can have the same formatting context inside as outside. It doesn't make sense for flex and grid containers since they always establish the new formatting context (different from the one they live in themselves) and therefore don't have issues like float leaking or descendant margin collapsing.

But I like the idea to have a separate property for switching new context generation on/off. Maybe this behavior has something to do with the scope of [css-containment], especially with contain:layout? Looks like something very similar from the first glimpse, and new formatting context is explicitly mentioned there.

P.S. Just after I posted this comment I found that the formatting context definition from [css-containment] already refers to flow-root as the inner display type. But maybe it could be contained in the contain spec, e.g. in form of "contain: formatting"?

As an option, we could have separate properties: one for self-clearing like self-clear, and another one for controlling collapsing margins like margin-collapse.

"flow-root" is completely non-intuitive. Given this is essentially a modification of display:block, I'm for a display property name that leads with "block" , as suggested above, a seperate property.

As an inner display value, "flow-root" can be also a modification of display:inline (resulting in display:inline-block behavior).

It was resolved in today's telcon we would not rename flow-root for lack of a name that seemed conclusively better.

Since that may be relevant to this thread, I would also note that the two-value syntax was proposed to be removed from the current draft last face-to-face, and possibly postponed for a later level.

Though at the risk of getting @fantasai to roll her eyes at me not proposing this during the call, I wonder if "display: block-bfc" doesn't indeed convey the meaning better (as well as starting to educate people on what a bfc is and does).

Though it may also add confusion, I don't know. Not sure I am convinced myself :)

I do not agree to change the name, as long as the specification is written clearly enough, the author understands the concept of BFC(block formatting context) naturally know what display: flow-root can do.