[css-multicol][css-break] break-* properties and non-paged media; "break-fill" property proposal for child elements

[rachelandrew]

Issue raised on www-style 3 Jan 2014, I don't see any discussion about it.

The Candidate recommendation indicates (in the property index) that the
following properties are intended only for paged media:

• break-before
• break-inside
• break-after

This is wrong because this also affects non-paged medias where it is highly
desirable to control where column breaks (not page breaks) are allowed or
wanted.

This is a confusion with the following properties only for paged medias:

• page-break-before
• page-break-inside
• page-break-after

Also the multicolumn layout is still missing a property to indicate how to
fill the remainining unused parts at end of columns, when break controls
are used.

We should have a "break-fill" property usable in child block elements to
define if their length should be extended (or not) to fill this area, so
that columns containing visible box borders will line up at the bottom. The
effect of "break-fll would be to increase the computed height (with
horizontal text directions) or the computed width (with vertical text
direction) so that it will line-up with the end position of the column.

As child block elements in a multi-column parent element could potentially
have different margins, special care must be taken for the vertical end
margin of these child elements (for horizontal texts where columns are
stacked horieontally): what is extended to line up should be the
margin-box, not the border-box or the content-box of these child elements.
But the margins and borders should be preserved, only the content-height is
extended

This would allow perfect alignement, and would also allow the last child
element in a column to use vertical alignement, or bottom alignement to
line up correctly at end of all columns.

For now we have "column-fill" specified only at the parent element, but
with only two values that aren't enough to cover cases: we will want to
control which child elements should have their height extended to fill the
column. With the "balance" option, it is assumed (incorrectly) that all
child elements should be proportionally adjusted. However we may want to
have specific child elements to keep their current computed height, while
the other child elements in the column would participate (proportionally to
their computed minimum height) to the column filling.

The default way to handle "column-fill: balance" would be to distribute the
extra height to all child block elements, unless these child elements use a
"break-fill: preserve" atribute to keep their length.

The default way to handle "column-fill: auto" would be to not distribute
this extra height to child block elements, except if some child elements
use a "break-fill: extend" attributeto increase their length.

The "break-fill" property would then have the following values:

• auto (default value)
• preserve
• extend

The auto (default) value of "break-fill" property of child elements means
that the child elements wll adopt the "preserve" or "extend" behavior
deoending on the "column-fill" setting of the parent multi-column block.

It is only if either:

• the parent multi-column element uses the "column-fill: auto" property
  and no child element uses "break-fill: extend"; or
• the parent multi-column element uses the "column-fill: balance"
  property and no child element uses "break-fill: preserve"

that no child element will adjusted in length, and the extra space will be
left empty (by extending the padding area of the parent on its end side)
(children elements will then stack in the column leaving an unused hole at
end of the column).

Also, ideally, the padding area of the parent multi-column element should
be used as part of the vertical (if horizontal text with colulns stacked
horizontally) margins of child elements if they are at the start or end of
the column.

Finally the specification shoud state where column breaks are still
undesirable : it should avoid cutting a line box (of a child element) in
the middle (as seen in Google Chrome), even if the child elemenr's
"break-inside:" computed value allows breaks. This would be consistant with
the possible extra control of orphan or widow line-boxes of child block
elements. And inline elements within line-boxes should also not be cut in
two parts by a column break (also seen for now in Google Chrome) if some
inline elements (such as icon images) are overflowing the line box or the
content-box of the child element : they should overflow :

And it will be up to the child element to specify what to do with their
vertically overflowing content (truncate or render in superposition), or to
the parent multi-column element to say if it wishes to hide or render parts
of child elements (or extra columns) that could be overflowing the
content-box of the parent.

[atanassov]

The spec is explicit about allowing break-before | inside | after for any media type, so perhaps this was misunderstood by the filer of the issue. Also, the spec is explicit about how boxes that are broken across a fragmentainer are supposed to extend and fill fragments (see https://drafts.csswg.org/css-break-3/#box-splitting)

As for the rest of the extend and/or balancing feature requests, my suggestion is to consider if this makes sense for multicolumn first and then we will evaluate if any other fragmentation affordances are missing.