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

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Vincent Hardy
Sent: Thursday, July 14, 2011 4:54 PM

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.

[am] thanks Vincent, this is a good start for pagination spec.

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).

[am] definitely agree that there must be one set of rules for breaking in  regions and pages. Current breaking rules are severely underspecified though, we are expected to make them more specific. Looking forward to that...

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>)

[am] we just went through a syntax change when column breaks were added. It would be great to not add a third syntax. I don't think adding "break-before:region" is bad enough to require new syntax.

[am] speaking of "break-xxx:region" - its potential use is uncertain so far, which makes it hard to discuss its value. We need use cases that use column, page and region breaks together, and agree on desired behavior (such as example 2 below, which I disagree with).

[am] Let's consider a use case like this:
[am]     - Page view on a tablet device uses <div> elements for pages, manipulating visibility or z-order as user flips pages.
[am]     - Each "page" has several regions, used for irregular-shaped "columns".
[am]     - Alternatively, top-level "pages" may also be regions, and "column" regions are in a nested flow, possibly using positioning an forced breaks to form individual pages.

[am] In this situation, what effect will each value of 'break-before' have? Would be great to be able to say that "break-before:column" goes to next "column" region and "break-before:page" goes to first region on next "page". But current spec doesn't provide enough clues for layout to make it happen, such behavior can only be achieved with specialized script.

Behavior for breaks in nested flows.

- 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).

[am] What is the meaning of "layout type" in this context? There is no such thing as "column layout" as far type of content is concerned, it is normal flow (usually) which may be in a column, region, page or all of the above...

- 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.

[am] I think I disagree, but probably not specifically with this and previous points but rather with some of decisions on break interactions... I'd like to get to an agreement on use cases and then get back to this.

- 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).

[am] yes, although "parent layout" is not the right term. "parent layout" may be anything; being in paged media (or not) does change how column breaking works...

- 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.

[am] this sounds reasonable. I should get merged with the prose in CSS3 Paged Media section 9 http://dev.w3.org/csswg/css3-page/#page-breaks (the definitions for how breaking properties on nested elements interact and behavior of split boxes - margins and borders between pages)

- 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.

[am] I think No. It is possible to make one column break to have effect in two nested column layouts, probably not even too hard (it would do the same thing as page break in a column in a page in print media, and the latter should work anyway). It doesn't seem super useful though, and it will need additional break options, I don't think it is worth it...

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.

[am] I agree, this is how it is now defined (page breaks have no effect unless in pages). I have a concern however that in this situation a page break is not stronger than a column break, while otherwise a page break is always a column break (let's talk more about break hierarchy, I don't think we covered that much yet).

[am] I'd like to consider an option that in this case page break is not ignored but treated as column break. E.g. if a style requires that <h1> has page break before, in multicol it at least gets at top of a column. Wouldn't that make sense?

[am] Tried this in current multicol implementations (attached), there isn't interop to speak of
[am] - IE10 Preview2: column break honored, page break ignored in normal view, honored in print preview
[am] - Safari: column break honored in normal view, no columns in print preview
[am] - Opera 11.5: column break honored in normal view, no text in print preview
[am] - Firefox ????: column break honored, page break has no effect (including print preview)

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.

[am] I have a number of issues with this.
[am] 1) I would really like a forced page break to always cause a region break. When reusing stylesheets from paged media, it seems much more useful to honor page breaks then simply ignoring them. It doesn't contradict adding more breaking properties to such styles to have finer control.
[am] 2) What happens when this content is printed, and let's say "r2" is on the next page. Will we expect that page breaks are still ignored because they are nested in regions (that would be odd, that would mean page breaks never have any effect in regions)? Or will a page break move "p1" to "r2" (I think that would be reasonable to expect, but also odd because inner flow doesn't flow directly through printed pages, it flows through a set of custom containers, and elsewhere flow inside regions doesn't interact with content outside regions....)?

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.

[am] I like option 1. Column break has effect at nearest multicolumn layout only.


[am] I have a couple of ideas for how to get a good behavior across tree modes (normal view, paged media, interactive page view with regions). I'll write it up separately.

Alex