You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-display] "flow-root" is a confusing value for display #964
The only place that CSS uses the term "flow" is in Regions (flow-from, flow-into). I think it's super confusing to have a "flow-root" value that isn't region-related, and authors don't know the term "flow layout".
+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:
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.
Reacted by Ilya Streltsyn, Marat Tanalin, Kumar Nitesh, Benji Bilheimer and Jannik
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.
@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:)
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.
There is a problem with "flow-block" suggestion: there is already a display: block flowlonghand 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.
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.
Activity
astearns commentedon Jan 21, 2017
+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'?
dbaron commentedon Jan 21, 2017
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.SelenIT commentedon Jan 21, 2017
@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:
If
display:flow-rootaffects all of these, I suppose that naming should also reflect them all.mrego commentedon Jan 23, 2017
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.
SelenIT commentedon Jan 23, 2017
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, orseparate-block, or justnew-block(since it establishes the new BFC)?tabatkins commentedon Jan 23, 2017
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.)
fantasai commentedon Jan 23, 2017
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.
js-choi commentedon Jan 24, 2017
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.
nadangergeo commentedon Jan 25, 2017
I propose "display: river", because there's a flow, and elements can float. To metaphorical maybe?
SelenIT commentedon Jan 25, 2017
@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-rootis 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:)Marat-Tanalin commentedon Jan 26, 2017
There is nothing wrong with the
flow-rootkeyword, it is quite clear and natural based on what it does.Fwiw, if renaming was required,
isolatedorcontextwould probably be viable options.inoas commentedon Jan 26, 2017
Considering
display: flow- and how I understand it should work - woulddisplay: flow-blockinstead ofdisplay: flow-rootmake sense?Just from the nomenclature it would also be in line with
display: blockvsdisplay: inline-blockin a way.alastc commentedon Jan 26, 2017
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?kalleboo commentedon Jan 26, 2017
Based on the description in the spec,
I like the "flow-block" suggestion by @inoas
SelenIT commentedon Jan 26, 2017
There is a problem with "flow-block" suggestion: there is already a
display: block flowlonghand value in the spec, which means just the opposite — the block that doesn't establish new block formatting context (i.e., defaultdisplay:blockbehavior). 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-rootas the inner display type. But maybe it could be contained in the contain spec, e.g. in form of "contain: formatting"?Marat-Tanalin commentedon Jan 26, 2017
As an option, we could have separate properties: one for self-clearing like
self-clear, and another one for controlling collapsing margins likemargin-collapse.Timoti commentedon Feb 1, 2017
"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.
SelenIT commentedon Feb 1, 2017
As an inner display value, "flow-root" can be also a modification of display:inline (resulting in display:inline-block behavior).
FremyCompany commentedon Feb 3, 2017
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.
FremyCompany commentedon Feb 3, 2017
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 :)
yisibl commentedon Feb 4, 2017
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 whatdisplay: flow-rootcan do.