W3C home > Mailing lists > Public > public-css-commits@w3.org > January 2012

csswg/css3-break Overview.html,1.14,1.15 Overview.src.html,1.15,1.16

From: Elika Etemad via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 25 Jan 2012 17:36:18 +0000
To: public-css-commits@w3.org
Message-Id: <E1Rq6le-0001ia-4U@lionel-hutz.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
+    &lsquo;<code class=css>top: calc(150% + 30px)</code>&rsquo; and has
+    &lsquo;<code class=css>height: calc(100% - 10px)</code>&rsquo;. 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:49 UTC