- From: Elika Etemad via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 25 Jan 2012 17:36:18 +0000
- To: public-css-commits@w3.org
Update of /sources/public/csswg/css3-break
In directory hutz:/tmp/cvs-serv6588
Modified Files:
Overview.html Overview.src.html
Log Message:
Rules for varying-width pagination, first cut, based on <http://lists.w3.org/Archives/Public/www-style/2011Sep/0301.html>
Index: Overview.html
===================================================================
RCS file: /sources/public/csswg/css3-break/Overview.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- Overview.html 25 Jan 2012 03:54:23 -0000 1.14
+++ Overview.html 25 Jan 2012 17:36:15 -0000 1.15
@@ -317,6 +317,13 @@
href="#fragmenter"><i>fragmenter</i></a>, in some cases causing a new
fragmenter to be generated to hold the deferred content.
+ <p> Breaking a fragmenter F effectively splits the fragmenter into two
+ fragmenters (F<sub>1</sub> and F<sub>2</sub>). The only difference is that
+ the type of break between the two pieces F<sub>1</sub> and F<sub>2</sub>
+ is the <a href="#break-types">type of break</a> created by the
+ fragmentation context that split F, not the type of break normally created
+ by F's own fragmentation context.
+
<p class=note> Breaking inline content into lines is another form of
fragmentation, and similarly creates box fragments when it breaks <a
href="http://www.w3.org/TR/CSS21/visuren.html#inline-boxes">inline
@@ -895,6 +902,83 @@
<h3 id=breaking-boxes><span class=secno>4.6. </span> Box Model for Breaking</h3>
+ <p> When a flow is fragmented into varying-size fragmenters, the following
+ rules are observed for adapting layout:
+
+ <ul>
+ <li> Intrinsic sizes are calculated and maintained across the entire
+ element. Where an initial containing block size is needed, assume an
+ initial containing block using the page's size of the first fragment's
+ page.
+
+ <li> Layout is performed per-fragmenter, with each fragmenter continuing
+ progress from the breakpoint on the previous, but recalculating sizes and
+ positions using its own size as if the entire element were fragmented
+ across fragmenters of this size. Progress is measured in percentages (not
+ absolute lengths) of used/available space and in amount of used/remaining
+ content.
+
+ <li> Fragments of boxes that began on a previous fragmenter must start at
+ the top of the new fragmenter. If this results in multiple floats
+ side-by-side that would otherwise be staggered (if they were not
+ continuations) in order to fit, the floats' widths are reduced (on that
+ fragmenter only) in proportion to their original widths until they fit.
+ However they are not reduced past their min-content width.
+ </ul>
+
+ <p>Below are listed some implications of these rules:
+
+ <ul>
+ <li> Boxes (including tables) fullfilling layout constraints at their
+ <i>fill-available</i> or percentage-based size may change measure across
+ pages.
+
+ <li> Boxes (including tables) fulfilling layout constraints at their
+ <i>min-content</i>, <i>max-content</i>, or absolute-length size will
+ maintain their measure across pages.
+
+ <li> Opposite-side side-by-side floats might overlap if, e.g. both begin
+ on a wide page, but their min-content measures taken together are too
+ wide to fit on a later, narrower page. (Auto-sized floats will not
+ overlap if only their max-content measures are too wide, since the
+ shrink-wrap algorithm will give them narrower measures due to the
+ narrower available measure.)
+
+ <li> Same-side side-by-side floats might overflow their containing block
+ if, e.g. both begin on a wide page, but their min-content measures taken
+ together are too wide to fit on a later, narrower page.
+ </ul>
+
+ <div class=example>
+ <p>Here is an example that shows the use of percentage-based progress:
+ Suppose we have an absolutely-positioned element that is positioned
+ ‘<code class=css>top: calc(150% + 30px)</code>’ and has
+ ‘<code class=css>height: calc(100% - 10px)</code>’. If it is
+ placed into a paginated context with a first page of 400px, a second page
+ of 200px, and a third page of 600px, its layout progresses as follows:
+
+ <ul>
+ <li>First, the top position is resolved against the first page's size.
+ This results in 630px. Since the first page only has 400px, layout moves
+ to the second page, recording progress of 400/630 = 63.49% with 36.51%
+ left to go.
+
+ <li>Now on the second page, the top position is again resolved, this time
+ against the second page size. This results in 330px. The remining 36.51%
+ of progress thus resolves to 120.5px, placing the top edge of the
+ element 120.5px down the second page.
+
+ <li>Now the height is resolved against the second page; it resolves to
+ 190px. Since there are only 79.5px left on the page, layout moves to the
+ third page, recording progress of 79.5/190 = 41.84%, with 48.16% left to
+ go.
+
+ <li>On the third page, the height resolves to 590px. The remaining 48.16%
+ of progress thus resolves to 246.9px, which fits on this page and
+ completes the element.
+ </ul>
+ </div>
+
<p> When an unforced break occurs between block-level boxes, any adjoining
margins are set to zero. When a forced break occurs there, any margins
before the break are truncated, but margins after the break are preserved.
Index: Overview.src.html
===================================================================
RCS file: /sources/public/csswg/css3-break/Overview.src.html,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -d -r1.15 -r1.16
--- Overview.src.html 25 Jan 2012 03:54:23 -0000 1.15
+++ Overview.src.html 25 Jan 2012 17:36:16 -0000 1.16
@@ -157,6 +157,14 @@
content.
</p>
+ <p>
+ Breaking a fragmenter F effectively splits the fragmenter into two
+ fragmenters (F<sub>1</sub> and F<sub>2</sub>). The only difference
+ is that the type of break between the two pieces F<sub>1</sub> and
+ F<sub>2</sub> is the <a href="#break-types">type of break</a> created
+ by the fragmentation context that split F, not the type of break
+ normally created by F's own fragmentation context.
+
<p class="note">
Breaking inline content into lines is another form of fragmentation,
and similarly creates box fragments when it breaks
@@ -670,6 +678,81 @@
Box Model for Breaking</h3>
<p>
+ When a flow is fragmented into varying-size fragmenters, the following
+ rules are observed for adapting layout:
+ </p>
+ <ul>
+ <li>
+ Intrinsic sizes are calculated and maintained across the entire element.
+ Where an initial containing block size is needed, assume an initial
+ containing block using the page's size of the first fragment's page.
+ <li>
+ Layout is performed per-fragmenter, with each fragmenter continuing
+ progress from the breakpoint on the previous, but recalculating sizes
+ and positions using its own size as if the entire element were fragmented
+ across fragmenters of this size. Progress is measured in percentages
+ (not absolute lengths) of used/available space and in amount of
+ used/remaining content.
+ <li>
+ Fragments of boxes that began on a previous fragmenter must start at
+ the top of the new fragmenter.
+ If this results in multiple floats side-by-side that would otherwise
+ be staggered (if they were not continuations) in order to fit, the
+ floats' widths are reduced (on that fragmenter only) in proportion to
+ their original widths until they fit. However they are not reduced
+ past their min-content width.
+ </ul>
+
+ <p>Below are listed some implications of these rules:</p>
+ <ul>
+ <li>
+ Boxes (including tables) fullfilling layout constraints at their
+ <i>fill-available</i> or percentage-based size may change measure
+ across pages.
+ <li>
+ Boxes (including tables) fulfilling layout constraints at their
+ <i>min-content</i>, <i>max-content</i>, or absolute-length size
+ will maintain their measure across pages.
+ <li>
+ Opposite-side side-by-side floats might overlap if, e.g. both begin
+ on a wide page, but their min-content measures taken together are
+ too wide to fit on a later, narrower page. (Auto-sized floats will
+ not overlap if only their max-content measures are too wide, since
+ the shrink-wrap algorithm will give them narrower measures due to the
+ narrower available measure.)
+ <li>
+ Same-side side-by-side floats might overflow their containing block
+ if, e.g. both begin on a wide page, but their min-content measures
+ taken together are too wide to fit on a later, narrower page.
+ </ul>
+
+ <div class="example">
+ <p>Here is an example that shows the use of percentage-based progress:
+ Suppose we have an absolutely-positioned element that is positioned
+ ''top: calc(150% + 30px)'' and has ''height: calc(100% - 10px)''. If
+ it is placed into a paginated context with a first page of 400px,
+ a second page of 200px, and a third page of 600px, its layout progresses
+ as follows:
+ <ul>
+ <li>First, the top position is resolved against the first page's size.
+ This results in 630px. Since the first page only has 400px, layout
+ moves to the second page, recording progress of 400/630 = 63.49% with
+ 36.51% left to go.
+ <li>Now on the second page, the top position is again resolved, this
+ time against the second page size. This results in 330px. The remining
+ 36.51% of progress thus resolves to 120.5px, placing the top edge of
+ the element 120.5px down the second page.
+ <li>Now the height is resolved against the second page; it resolves
+ to 190px. Since there are only 79.5px left on the page, layout moves
+ to the third page, recording progress of 79.5/190 = 41.84%, with 48.16%
+ left to go.
+ <li>On the third page, the height resolves to 590px. The remaining
+ 48.16% of progress thus resolves to 246.9px, which fits on this page
+ and completes the element.
+ </ul>
+ </div>
+
+ <p>
When an unforced break occurs between block-level boxes, any adjoining
margins are set to zero. When a forced break occurs there, any margins
before the break are truncated, but margins after the break are preserved.
Received on Wednesday, 25 January 2012 17:36:20 UTC