New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 660611 link

Starred by 7 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Feature



Sign in to add a comment

Support fragmentation in flexbox

Reported by dsong...@gmail.com, Oct 29 2016

Issue description

Chrome Version       : 54.0.2840.71
URLs (if applicable) : http://codepen.io/dsongman/pen/ORYeEa?editors=1100
Other browsers tested:
     Safari: FAIL (differently) - Renders text and input across columns
    Firefox: OK
         IE: OK
       Edge: OK

What steps will reproduce the problem?
(1) HTML:
<div class="wrapper">
  <div class="row">
    <label>Label</label><input type="text">
  </div>
  ... (more rows with same structure) ...
</div>
CSS:
.wrapper {
  column-count: 2
}
.row {
  display: flex;
}
(2) Input renders partially in both columns

What is the expected result?
Input should render either in first column or in second column.

What happens instead?
Lets assume there are 5 div.row within the div.wrapper. If the 3rd .row would render in the left column, the bottom pixel of the input renders at the top of the right column. If the 3rd row would render in the right column (by adding some padding, for example), the top of the input renders at the bottom of the left column and the bottom of the input renders in the top of the right column.

Screenshot attached and demo: http://codepen.io/dsongman/pen/ORYeEa
 
Screen Shot 2016-10-28 at 5.31.58 PM.png
10.7 KB View Download
Labels: Pri-1
Cc: kkaluri@chromium.org
Components: UI
Labels: OS-Linux OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on windows 10,Ubuntu 14.04 and Mac 10.11.6 using chrome stable M54-54.0.2840.71 
and earlier version of chrome M30-30.0.1549.0. This is a non-regression issue and marking it as untriaged.

Please look into the attached screencast.

Thank You...

Issue-660611.mp4
940 KB View Download
Components: -UI Blink>Layout>Flexbox

Comment 4 by e...@chromium.org, Jan 18 2017

Cc: cbiesin...@chromium.org msten...@opera.com
Morten/Christian, could either of you triage this?

Comment 5 by msten...@opera.com, Jan 19 2017

Status: Available (was: Untriaged)
The flexbox implementation doesn't really support fragmentation. I found no bug report for that. There is bug 606350, but that's actually just a prerequisite to implementing what https://www.w3.org/TR/css-flexbox-1/#pagination , i.e. proper support for breaking before and after flex items and lines.

In this particular test case you have a multicol container with a bunch of flex containers inside. Each flex container holds one unbreakable flex item. The correct behavior here would be to break between two flex containers, since there's (fragmentation-spec-wise) no break opportunity inside a flex container before its first item, or after its last item (only BETWEEN two items).

Christian, are you aware of a bug that says something along the lines of "Implement fragmentation for flex box"? I.e. similar to what we have for grid in bug 614667. If there is no such bug, I suppose we could hijack this bug for that purpose?

Comment 6 by e...@chromium.org, Feb 2 2017

Labels: -Pri-1 -Type-Bug Pri-2 Type-Feature
Summary: Support fragmentation in flexbox (was: Error rendering input in a flexbox row in multicolumn container)
Let's use this one to implement fragmentation.

Comment 8 by v...@g.nevcal.com, Jun 26 2017

Firefox has a nice implementation of flexbox break-*, and if Chromium implemented it, the feature would be reasonably useful to real web pages. Without the break-* features, flexbox is rather limited in its ability to do truly responsive designs (not that it isn't helpful in some case).
Cc: dholb...@gmail.com
I'm confused why you say that. break-* is only used for paginated media (usually printing). See https://lists.w3.org/Archives/Public/www-style/2015May/0065.html

Comment 10 by v...@g.nevcal.com, Jun 26 2017

https://www.w3.org/TR/css-flexbox-1/ describes how to use flexbox for fragmentation, not just for paginated media (in fact, other than using the same [updated] syntax [break-* rather than page-break-*], the fragmentation concept is quite independent of paginated media, although there are interactions when both are in use).

The fragmentation features allow control over row/column breaks in connection with wrapping, without requiring the row/column to be filled to force wrapping. This is powerful and useful, which is no doubt why it is included in the flexbox spec.

Simple things can be done easily with flexbox even without the fragmentation features, but complex things quickly require them to be possible at all.

Comment 11 by v...@g.nevcal.com, Jun 26 2017

"to use flexbox" in the first line of the last comment should be "to use break-*"
Cc: fanta...@inkedblade.net tabatkins@chromium.org
Can you clarify what section of the spec you think refers to applying break-* outside of paged media? I will note, again, that your interpretation contradicts the spec authors (as I quoted)

Comment 13 by v...@g.nevcal.com, Jun 26 2017

First, it is very obvious that the name change from "page-break-*" to "break-*" implies a move for using the syntax outside of paged media.

Second, the second paragraph of section 10 of the specification that I linked to in comment 10, says:

The following breaking rules refer to the fragmentation container as the “page”. The same rules apply in any other fragmentation context. (Substitute “page” with the appropriate fragmentation container type as needed.) See the CSS3 Fragmentation Module [CSS3-BREAK]. For readability, in this section the terms "row" and "column" refer to the relative orientation of the flex container with respect to the block flow direction of the fragmentation context, rather than to that of the flex container itself. 

My interpretation of "The same rules apply in any other fragmentation context" is that fragmentation contexts other than paged media exist.  In fact, the linked definition of "fragmentation context" in the spec defines 3 such contexts:

fragmentation context
    An ordered series of fragmentainers, such as created by a multi-column element, a chain of CSS regions, or a paged media display. A given fragmentation context can only have one block flow direction across all its fragmentainers. (Descendants of the fragmentation root may have other block flow directions, but fragmentation proceeds according to the block flow direction applied to the fragmentation root.) 


Third, while your link to an email about paged media is indeed a discussion including at least one of the authors, it predates the spec by a year, and discussions are often about specific arcana. Given the first two points, I didn't take time to attempt to understand the context of the email you referenced, but on the face, it seems to be about a particular interaction between fragmentation directions — how to handle the case where fragmentation is defined for two different directions. I may be misinterpreting it, but (1) it isn't the spec, and (2) it predates the spec, and (3) the spec clearly defines fragmentation contexts other than paged media.

Fourth, Firefox implements the feature as in the specification.

Does that clarify my position adequately?

Comment 14 by fanta...@gmail.com, Jun 26 2017

Wrt the message in comment #9, that discussion was about how the break-* properties do not affect flex-line breaking. (They also don't affect inline layout's line-breaking, fwiw.) They still affect pagination, multi-col, etc. as usual when used on flex containers & items.
Right -- so absent multicol/regions/other special cases, break-* has no effect on screen layout, right?
Also, v+python, what do you mean with "it predates the spec by a year"? Which spec? Both flexbox and the pagination spec have been around for a long time.

Comment 17 by v...@g.nevcal.com, Jun 26 2017

re: comment 14:
Having now read the whole archived email thread, I can agree that the discussion is about how break-* does not affect flex-line breaking EXCEPT if contained in a fragmentainer.

re: comment 15:
So digging deeper, and in spite of the Firefox implementation that applies break-* to wrapped flexbox rows, this comment is claiming that flexbox itself is not intended to be a "framentainer"? So to make break-* take effect on-screen within a flexbox, one would have to wrap it in a multicol (not very well supported) or region (hardly supported at all)?  From the fragmentation spec:

fragmentation container (fragmentainer)
    A box—such as a page box, column box, or region—that contains a portion (or all) of a fragmented flow. Fragmentainers can be pre-defined, or generated as needed. When breakable content would overflow a fragmentainer in the block dimension, it breaks into the next container in its fragmentation context instead. 

If this is the case, it would be extremely helpful if the flexbox spec section 10 pointed out that flexbox is not a fragmentainer, and that the fragmentation rules listed only apply when it is contained in an outer fragmentainer. The above definition hints at the ability to pre-define or generate fragmentainers... but doesn't say how. Region and multicol seem to be pre-defined ones, and maybe no others exist? It would be useful to have CSS that would allow a block, flexbox, etc. to be defined as a fragmentainer so that appropriate row breaks could be defined for flexbox. Otherwise, its functionality for complex responsive designs is extremely limited.

re: comment 16:
The spec I referenced has a 2016 date; the email referenced has a 2015 date.


So it appears that my interpretation of flexbox and break-* was biased by an assumption that flexbox itself is or could be a fragmentainer, and supported only by what now seems to be an inappropriate implementation of that same assupmtion within Firefox? And that, in spite of how useful and practical that is, it is not only not standard, but violates the standard?
> The spec I referenced has a 2016 date; the email referenced has a 2015 date.

Sure, that version of the spec does have a 2016 date, but this part has not meaningfully changed since the previous versions (e.g. https://www.w3.org/TR/2012/CR-css3-flexbox-20120918/#pagination)

> And that, in spite of how useful and practical that is, it is not only not standard, but violates the standard?

Correct.

I'll let Tab/fantasai respond to your other points.
None of this is about flex line breaking.  (That is, controlling when a flex line breaks.)  That is indeed not yet addressed in the break-* properties.

This is about a flexbox fragmenting across a fragmentation boundary (specifically, in a multicol). The break-* properties *do* apply here.  In particular, saying "break-inside: avoid" or "break-inside: avoid-column" *should* make the flexbox avoid breaking across the column boundary - if it would overlap the break point, it should move itself entirely to the next column.

<https://www.w3.org/TR/2012/CR-css3-flexbox-20120918/#pagination> is about better automatic fragmentation behavior for a flexbox. (Again, still not related to flex-line breaking.)  Our current behavior (visually slice the element) is terrible by any metric, and not supported by any spec text; we've just traditionally had a terrible fragmentation implementation, and this is the best we can do without a ton of hacky effort.  (This also happens with all layout modes; flexbox isn't special here. I use block-in-multicol on a personal site, and run into this frustrating "top border was left behind on the previous column" effect there too.)  LayoutNG will make this *substantially* better, so we can actually fragment properly.

In the absence of LayoutNG making flexbox automatically fragment well, it *would* be really cool if we could, at least, support the break-* properties on children of a multicol, so we can at least prevent this terrible visual slicing behavior.
Project Member

Comment 20 by sheriffbot@chromium.org, Jun 28

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Pri-2 Pri-3
Status: Available (was: Untriaged)

Sign in to add a comment