- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Thu, 20 Oct 2011 19:14:21 +0000
- To: "www-style@w3.org list" <www-style@w3.org>
- Message-ID: <D51C9E849DDD0D4EA38C2E539856928412D158AB@TK5EX14MBXC214.redmond.corp.microsoft.>
(I wrote this up for July 2011 F2F... some of it may have been discussed and/or resolved at the F2F but somehow not shared here)
From: Alex Mogilevsky
Sent: Saturday, July 23, 2011 3:41 PM
It seems that in all region issues we are farthest from consensus on region breaks. I've written up my thoughts on this and issues to consider. Hope it will help to get to an agreement...
0. Flow content for use cases
Let's consider same simple content in a number of situations. It has one forced column break and one forced page break:
use-case-content =
<p id="p_0">0...</p>
<p id="p_1" style="break-before:column">1...</p>
<p id="p_2" style="break-before:page">2...</p>
<p id="p_3">3...</p>
1. Multicolumn layout in normal view
Content is in an element with multicolumn layout.
Media resolves to "screen".
Width and height are assumed to be sufficient to fit content with no overflow or breaks.
Column balancing is off.
<div style="columns:3; width:300px; height:auto; column-fill:auto">
{use-case-content}
</div>
Result 1a (current specs): column break has effect, page break ignored in screen media
----------------------------
| 0... | 1... | |
| | 2... | |
| | 3... | |
----------------------------
Note: the behavior is defined, but it is not necessarily consistent with intuitive understanding of pages and columns. The author wanted a page break, it would not be unreasonable to get at least a column break.
Result 1b (possible alternative interpretation): page break becomes a column break
----------------------------
| 0... | 1... | 2... |
| | | 3... |
----------------------------
2. Multicolumn layout in paged media
Same content is viewed in print preview or printed on paper
Page size is enough to fit the whole multicol box
(Current spec doesn't fully define how page breaks affect multicolumn layout in paged media)
Result 2a (page break ignored in multicol):
*** page 1 ***********************
* ---------------------------- *
* | 0... | 1... | | *
* | | 2... | | *
* | | 3... | | *
* ---------------------------- *
* *
**********************************
Result 2b (page break breaks multicol box):
*** page 1 ***********************
* ---------------------------- *
* | 0... | 1... | | *
* | | | | *
* | | | | *
* | | | | *
* | | | | *
**********************************
(border and background continue to bottom of page; no bottom border)
(no top border on next page)
*** page 2 ***********************
* | 2... | | | *
* | 3... | | | *
* ---------------------------- *
* *
* *
* *
**********************************
This should be the preferred result, consistent with treatment of page and column breaks in a word processor.
3. Multicolumn layout in region "pages"
Let's consider a full-screen paginated reading view, constructed like this:
<div id="region_page1" style="position:fixed; width:100%; height:100%; flow-from:article"></div>
<div id="region_page2" style="position:fixed; width:100%; height:100%; flow-from:article"></div>
"page" elements are visible one at a time, script changes z-order to turn pages.
Same multicolumn content is placed into a named flow consumed by full-screen regions
<div style="flow-into:article">
<div style="columns:3; width:300px; height:auto; column-fill:auto">
{use-case-content}
</div>
</div>
Result 3a (page break ignored):
*** region_page1 *****************
* ---------------------------- *
* | 0... | 1... | | *
* | | 2... | | *
* | | 3... | | *
* ---------------------------- *
* *
**********************************
We will get this if page breaks are still for paged media only, and this is not paged media.
Result 3b (page break region break):
*** region_page1 *****************
* ---------------------------- *
* | 0... | 1... | | *
* | | | | *
* | | | | *
* | | | | *
* | | | | *
**********************************
*** region_page2 *****************
* | 2... | | | *
* | 3... | | | *
* ---------------------------- *
* *
* *
* *
**********************************
For this experience it is desirable to treat page break as region break. But is may not always be the right choice.
4. Regions as columns
A full-page reading magazine application could also be built like this:
<div id="div_page1" style="position:fixed; width:100%; height:100%;">
<div id="region_column1" style="width:30%; margin:0 1.5%; height:100%; flow-from:article"></div>
<div id="region_column2" style="width:30%; margin:0 1.5%; height:100%; flow-from:article"></div>
<div id="region_column3" style="width:30%; margin:0 1.5%; height:100%; flow-from:article"></div>
</div>
<div id="div_page2" style="position:fixed; width:100%; height:100%;">
<div id="region_column4" style="width:30%; margin:0 1.5%; height:100%; flow-from:article"></div>
<div id="region_column5" style="width:30%; margin:0 1.5%; height:100%; flow-from:article"></div>
<div id="region_column6" style="width:30%; margin:0 1.5%; height:100%; flow-from:article"></div>
</div>
Content is flown directly into the regions, multicolumn layout is not used:
<div style="flow-into:article">
{use-case-content}
</div>
Result 4a (no forced breaks):
*** div_page1 ********************
* | 0... | | | *
* | 1... | | | *
* | 2... | | | *
* | 3... | | | *
**********************************
If regions are not pages and not columns, we get this
Result 4b (page break is region break):
*** div_page1 ********************
* | 0... | 2... | | *
* | 1... | 3... | | *
* | | | | *
* | | | | *
**********************************
Page break has effect, but not column break. The result is different from design intent (if the design is for paginated multicolumn layout - 2b).
Result 4c (column break and page break are region breaks):
*** div_page1 ********************
* | 0... | 1... | 2... | *
* | | | 3... | *
* | | | | *
* | | | | *
**********************************
This may be preferable in some cases but not here - still not a match for design intent
Result 4d (elements used for columns and pages are marked as such - currently not possible):
*** div_page1 ********************
* | 0... | 1... | | *
* | | | | *
* | | | | *
* | | | | *
**********************************
*** div_page2 ********************
* | 2... | | | *
* | 3... | | | *
* | | | | *
* | | | | *
**********************************
This would be ideal, but to achieve this result there has to be away to mark these regions as columns and counting divs as pages.
Also content of "page" divs have to be considered being in paged media, or page breaks have to be allowed.
Options for interpreting breaks in regions and columns
A. Page breaks in regions are always region breaks
B. Column breaks and page breaks in regions are always region breaks
C. Column breaks in regions are region breaks; page breaks in regions are not region breaks
D. Add new break type "break-xxx:region". Column breaks and page breaks have no meaning for regions.
E. Add properties to designate containers as pages or columns.
Options like A to C (and any similar permutations) work with different success but none get to perfect results when complex layout is modeled with regions.
Option D adds more control (and more complexity too) while still providing only one level of control (while columns/pages in paged media have two).
Option E has potential for expressing design intent exactly (at the cost of requiring additional properties).
Proposal
I think option E is the most promising. It needs a new property:
Name:
flow-container-type
Value:
auto | page | column | inherit
Initial:
auto
Applies to:
block elements
Inherited:
no
Percentages:
N/A
Media:
visual
Computed value:
as specified
Setting this property on a region can designate it as a column or page. Then page and column breaks in content can be interpreted according to design of the overall layout.
Also, setting "flow-container-type:page" on a div containing multiple regions makes it possible to understand which regions are on same page or not and interpret breaks accordingly. Similarly "flow-container-type" can be set on nested regions, with same effect.
When 'flow-container-type' with same value is set on nested elements, only the nearest parent is taken into account when considering breaks in content. 'page' container within 'column' container hides parent 'column' from its content (column break can't split a page container).
Enabling paged media styles in fragmented flow
Note (2011/10/20): this was discussed at July F2F and my proposal of treating regions a "paged media" is not the way to go.
When content is displayed in a chain of linked containers, its layout behavior is closer to printed pages than to screen. It would make sense to enable styles designed for pages in that situation. However "paged media" styles often assume "not interactive", so it is not always a clear choice.
Options for enabling custom styles in regions
PM1. Consider flow in regions "paged media"
(limiting - regions design includes regions that don't paginate)
PM2. Create a new media type for regions
(possible, may be way to go if no existing media type is a good match; probably won't work for same reason as 1 and 4)
PM3. Create a "named flow" selector for media queries
(not very useful - also because some regions paginate and some not)
PM4. Mark elements as paged media containers
(could only work if region styles worked, with a lot of added complexity. Non-starter)
PM5. Mark named flows as paged media
(good choice for control; also needs a new property)
Of these, I think only PM5 is workable. Could be something like "flow-container-media:print" (consistent with whatever name is picked for container type)
Is page break a column break?
An issue mostly orthogonal to above choices, but relevant. I think the definition of page break should be updated so that a forced page break always causes a column break when within multicolumn layout. Also 'break-inside:avoid-page' also implies 'avoid-column'. Would that be reasonable? Any downsides from treating page and column breaks as strict hierarchy (add line breaks into the hierarchy and it still works)?
What do you think?
Alex
Received on Thursday, 20 October 2011 19:14:57 UTC