Skip to content

Commit 8619971

Browse files
fantasaifantasai
committed
Rules for varying-width pagination, first cut, based on <http://lists.w3.org/Archives/Public/www-style/2011Sep/0301.html>
1 parent 4de2215 commit 8619971

2 files changed

Lines changed: 167 additions & 0 deletions

File tree

‎css3-break/Overview.html‎

Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -317,6 +317,13 @@ <h2 id=fragmentation-model><span class=secno>2. </span> Fragmentation Model
317317
href="#fragmenter"><i>fragmenter</i></a>, in some cases causing a new
318318
fragmenter to be generated to hold the deferred content.
319319

320+
<p> Breaking a fragmenter F effectively splits the fragmenter into two
321+
fragmenters (F<sub>1</sub> and F<sub>2</sub>). The only difference is that
322+
the type of break between the two pieces F<sub>1</sub> and F<sub>2</sub>
323+
is the <a href="#break-types">type of break</a> created by the
324+
fragmentation context that split F, not the type of break normally created
325+
by F's own fragmentation context.
326+
320327
<p class=note> Breaking inline content into lines is another form of
321328
fragmentation, and similarly creates box fragments when it breaks <a
322329
href="http://www.w3.org/TR/CSS21/visuren.html#inline-boxes">inline
@@ -895,6 +902,83 @@ <h3 id=best-pg-brk><span class=secno>4.5. </span> Optimizing Unforced
895902

896903
<h3 id=breaking-boxes><span class=secno>4.6. </span> Box Model for Breaking</h3>
897904

905+
<p> When a flow is fragmented into varying-size fragmenters, the following
906+
rules are observed for adapting layout:
907+
908+
<ul>
909+
<li> Intrinsic sizes are calculated and maintained across the entire
910+
element. Where an initial containing block size is needed, assume an
911+
initial containing block using the page's size of the first fragment's
912+
page.
913+
914+
<li> Layout is performed per-fragmenter, with each fragmenter continuing
915+
progress from the breakpoint on the previous, but recalculating sizes and
916+
positions using its own size as if the entire element were fragmented
917+
across fragmenters of this size. Progress is measured in percentages (not
918+
absolute lengths) of used/available space and in amount of used/remaining
919+
content.
920+
921+
<li> Fragments of boxes that began on a previous fragmenter must start at
922+
the top of the new fragmenter. If this results in multiple floats
923+
side-by-side that would otherwise be staggered (if they were not
924+
continuations) in order to fit, the floats' widths are reduced (on that
925+
fragmenter only) in proportion to their original widths until they fit.
926+
However they are not reduced past their min-content width.
927+
</ul>
928+
929+
<p>Below are listed some implications of these rules:
930+
931+
<ul>
932+
<li> Boxes (including tables) fullfilling layout constraints at their
933+
<i>fill-available</i> or percentage-based size may change measure across
934+
pages.
935+
936+
<li> Boxes (including tables) fulfilling layout constraints at their
937+
<i>min-content</i>, <i>max-content</i>, or absolute-length size will
938+
maintain their measure across pages.
939+
940+
<li> Opposite-side side-by-side floats might overlap if, e.g. both begin
941+
on a wide page, but their min-content measures taken together are too
942+
wide to fit on a later, narrower page. (Auto-sized floats will not
943+
overlap if only their max-content measures are too wide, since the
944+
shrink-wrap algorithm will give them narrower measures due to the
945+
narrower available measure.)
946+
947+
<li> Same-side side-by-side floats might overflow their containing block
948+
if, e.g. both begin on a wide page, but their min-content measures taken
949+
together are too wide to fit on a later, narrower page.
950+
</ul>
951+
952+
<div class=example>
953+
<p>Here is an example that shows the use of percentage-based progress:
954+
Suppose we have an absolutely-positioned element that is positioned
955+
&lsquo;<code class=css>top: calc(150% + 30px)</code>&rsquo; and has
956+
&lsquo;<code class=css>height: calc(100% - 10px)</code>&rsquo;. If it is
957+
placed into a paginated context with a first page of 400px, a second page
958+
of 200px, and a third page of 600px, its layout progresses as follows:
959+
960+
<ul>
961+
<li>First, the top position is resolved against the first page's size.
962+
This results in 630px. Since the first page only has 400px, layout moves
963+
to the second page, recording progress of 400/630 = 63.49% with 36.51%
964+
left to go.
965+
966+
<li>Now on the second page, the top position is again resolved, this time
967+
against the second page size. This results in 330px. The remining 36.51%
968+
of progress thus resolves to 120.5px, placing the top edge of the
969+
element 120.5px down the second page.
970+
971+
<li>Now the height is resolved against the second page; it resolves to
972+
190px. Since there are only 79.5px left on the page, layout moves to the
973+
third page, recording progress of 79.5/190 = 41.84%, with 48.16% left to
974+
go.
975+
976+
<li>On the third page, the height resolves to 590px. The remaining 48.16%
977+
of progress thus resolves to 246.9px, which fits on this page and
978+
completes the element.
979+
</ul>
980+
</div>
981+
898982
<p> When an unforced break occurs between block-level boxes, any adjoining
899983
margins are set to zero. When a forced break occurs there, any margins
900984
before the break are truncated, but margins after the break are preserved.

‎css3-break/Overview.src.html‎

Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -157,6 +157,14 @@ <h2 id="fragmentation-model">
157157
content.
158158
</p>
159159

160+
<p>
161+
Breaking a fragmenter F effectively splits the fragmenter into two
162+
fragmenters (F<sub>1</sub> and F<sub>2</sub>). The only difference
163+
is that the type of break between the two pieces F<sub>1</sub> and
164+
F<sub>2</sub> is the <a href="#break-types">type of break</a> created
165+
by the fragmentation context that split F, not the type of break
166+
normally created by F's own fragmentation context.
167+
160168
<p class="note">
161169
Breaking inline content into lines is another form of fragmentation,
162170
and similarly creates box fragments when it breaks
@@ -669,6 +677,81 @@ <h3 id="best-pg-brk">
669677
<h3 id="breaking-boxes">
670678
Box Model for Breaking</h3>
671679

680+
<p>
681+
When a flow is fragmented into varying-size fragmenters, the following
682+
rules are observed for adapting layout:
683+
</p>
684+
<ul>
685+
<li>
686+
Intrinsic sizes are calculated and maintained across the entire element.
687+
Where an initial containing block size is needed, assume an initial
688+
containing block using the page's size of the first fragment's page.
689+
<li>
690+
Layout is performed per-fragmenter, with each fragmenter continuing
691+
progress from the breakpoint on the previous, but recalculating sizes
692+
and positions using its own size as if the entire element were fragmented
693+
across fragmenters of this size. Progress is measured in percentages
694+
(not absolute lengths) of used/available space and in amount of
695+
used/remaining content.
696+
<li>
697+
Fragments of boxes that began on a previous fragmenter must start at
698+
the top of the new fragmenter.
699+
If this results in multiple floats side-by-side that would otherwise
700+
be staggered (if they were not continuations) in order to fit, the
701+
floats' widths are reduced (on that fragmenter only) in proportion to
702+
their original widths until they fit. However they are not reduced
703+
past their min-content width.
704+
</ul>
705+
706+
<p>Below are listed some implications of these rules:</p>
707+
<ul>
708+
<li>
709+
Boxes (including tables) fullfilling layout constraints at their
710+
<i>fill-available</i> or percentage-based size may change measure
711+
across pages.
712+
<li>
713+
Boxes (including tables) fulfilling layout constraints at their
714+
<i>min-content</i>, <i>max-content</i>, or absolute-length size
715+
will maintain their measure across pages.
716+
<li>
717+
Opposite-side side-by-side floats might overlap if, e.g. both begin
718+
on a wide page, but their min-content measures taken together are
719+
too wide to fit on a later, narrower page. (Auto-sized floats will
720+
not overlap if only their max-content measures are too wide, since
721+
the shrink-wrap algorithm will give them narrower measures due to the
722+
narrower available measure.)
723+
<li>
724+
Same-side side-by-side floats might overflow their containing block
725+
if, e.g. both begin on a wide page, but their min-content measures
726+
taken together are too wide to fit on a later, narrower page.
727+
</ul>
728+
729+
<div class="example">
730+
<p>Here is an example that shows the use of percentage-based progress:
731+
Suppose we have an absolutely-positioned element that is positioned
732+
''top: calc(150% + 30px)'' and has ''height: calc(100% - 10px)''. If
733+
it is placed into a paginated context with a first page of 400px,
734+
a second page of 200px, and a third page of 600px, its layout progresses
735+
as follows:
736+
<ul>
737+
<li>First, the top position is resolved against the first page's size.
738+
This results in 630px. Since the first page only has 400px, layout
739+
moves to the second page, recording progress of 400/630 = 63.49% with
740+
36.51% left to go.
741+
<li>Now on the second page, the top position is again resolved, this
742+
time against the second page size. This results in 330px. The remining
743+
36.51% of progress thus resolves to 120.5px, placing the top edge of
744+
the element 120.5px down the second page.
745+
<li>Now the height is resolved against the second page; it resolves
746+
to 190px. Since there are only 79.5px left on the page, layout moves
747+
to the third page, recording progress of 79.5/190 = 41.84%, with 48.16%
748+
left to go.
749+
<li>On the third page, the height resolves to 590px. The remaining
750+
48.16% of progress thus resolves to 246.9px, which fits on this page
751+
and completes the element.
752+
</ul>
753+
</div>
754+
672755
<p>
673756
When an unforced break occurs between block-level boxes, any adjoining
674757
margins are set to zero. When a forced break occurs there, any margins

0 commit comments

Comments
 (0)