[css3-regions] ACTION 330: Regions spec. editors to specify a model for breaking flow content

Hello,

This email is the result of looking at the precedents on breaking content in the CSS 2.1 specification and the CSS 3 Paged Media and CSS 3 Multi-column layout drafts.

References:

- CSS 2.1 Page Breaks: http://www.w3.org/TR/CSS21/page.html#page-break-props
  (section 13.3)
- Paged Media Module Level 3 (Editor Draft October 25 2010)
  http://dev.w3.org/csswg/css3-page/#page-breaks (section 9)
- CSS Multi-column Layout Module (Editor Draft May 15 2011)
   http://dev.w3.org/csswg/css3-multicol/#column-breaks (section 5)
- CSS Regions (Editor Draft July 1 2011)
  http://dev.w3.org/csswg/css3-regions/#flow-breaking-rules (section 2.3 and 3.4)

The action item was:

"Regions spec. editors to specify a model for breaking flow content across areas that accounts for regions, columns and pages. Build on paged media and propose behavior for nested flows breaks."

- Model for breaking flow content.

Proposal: keep the same model as defined in Paged Media. Reword to account for regions (sections 9.4/9.5/9.6 on allowed/forced/best page breaks). This is pretty much what is in the current draft for CSS Regions (as of July 13th 2011).

- Properties for breaking content.

I suggest a syntax change:

- break-before and break-after: auto | force(<layout>) | avoid(<layout>)
where <layout> would be page, column or region.
- break-inside: auto | avoid(<layout>)

- Behavior for breaks in nested flows.

Nesting flows are situations where, for example, a multi-column element happens in a page flow or a region is part of a column layout or a multi-column layout is in a region.

This could be expressed as: L1 -> L2 -> ... -> LN

Where L1 is the root layout and L(n-1) depends on L(n).

The proposed general behavior is:

- break-* properties tag the content for break opportunities or restrictions for specific layout types. So the content is 'annotated' (so to speak) with requests to break or not-break, and these marks are for specific layout types (column, region, page).

- A layout only looks at the layout opportunities relevant for its own type. The column layout, when laying out its content, only looks at the column layout annotations. It does not look at region break annotations or at page break annotations.

- A layout may behave differently depending on its parent layout. For example, a multi-column layout may insert a page break if it needs to generate a new column box and the parent layout is a page layout (see http://www.w3.org/TR/2011/CR-css3-multicol-20110412/#pagination-and-overflow-outside-multicol).

- A layout may split some of the boxes it lays out and trigger a new layout of the nested layout. For example, a page break in a multi-column element will cause a column break and a new row of columns to be created (and laid out) in the new page box.

- Open issue: it is not clear if breaks that have been 'used' should be disabled or if they still identify break opportunities for higher level layouts. For example, in the case of two nested multi-column layouts, if a column break was used in the inner multi-column element, is it still identifying a break opportunity for the higher level multi-column element? See the last use case below.

Use Cases

I. Multi-column and page breaks

<div style="columns:3">
<p id="p_0">...</p>
<p id="p_1" style="break-before:page">...</p>
<p id="p_2" style="break-after:column">...</p>
<p id="p_3">...</p>
</div>

In continuous media, the page break is ignored and only the column break is honored by the multi-column layout.

In paged media, the column layout does a first layout and accounts for the column break in p_2. The paged layout then accounts for the page break, splits the multi-column element. This causes the column element to generate a new row with column boxes and layout. This is then laid out on the new page box.

II. Regions and page breaks

<div id="r0" style="content:from-flow(article)">
</div>

<div id="r1" style="content:from-flow(article)">
</div>

<div id="r2" style="content:from-flow(article)">
</div>

<div style="flow:article">
<p id="p_0">...</p>
<p id="p_1">... <span style="break-before:page">...</span>...</p>
<p id="p_2" style="break-after:region">...</p>
<p id="p_3">...</p>
</div>

Let's suppose that p_0 can be laid out in r0 entirely and that some half of p_1 could be laid out into r_0 as well. Let's further assume that the second half of p_1 and all of p_2 and some of p_3 would fit in r1.

The content would render identical to:

<div id="r0">
<p id="p_0">...</p>
<p id="p_1_part_1" style="break-before:page">...</p>
 </div>

<div id="r1">
<p id="p_1_part_2">...</p>
<p id="p_2"><span>...</span> ...</p>
</div>

<div id="r2">
<p id="p_3">...</p>
</div>

which is the result of the region layout and then the page layout would apply.

III. Nested Multi-Column Elements

<div id="d1" style="columns:3">
<div id="d_11">...</div>
<div id="d_12" style="columns:3">
    <p id="p_0">...</p>
         <p id="p_1">...</p>
    <p id="p_2" style="break-after:column">...</p>
    <p id="p_3">...</p>
</div>
<div id="d_13" style="break-before: column">...</div>
</div>

In this use case, there are two multi-column elements, one nested in the other. The inner multi-column has a child (p_2) with break-after:column. This break could represent:

1. a forced break for d_12 (the innermost multi-column element)
2. a forced break for d1 (the outermost multi-column element)
3. a forced break for both d_12 and d1

If we decide on 1., then we cannot force the generation of a new row of columns in the next column of the outer multi-col but we can force the generation of a new row of columns in the next page (by using break-after: page). This is a limitation, not necessarily a show stopper.

If we decide on 2., it seems difficult because the effect of the break property varies depending on the context the element is found. So if we now nest d1 in another multi-column, then the property would apply to that new outer multi-column element.

If we decide on 3., then we lose the ability to only break on the inner element which seems to be the most common use case.

So the first option (apply to the innermost multi-column element) seems the best option.