Define fragment indices so that fragments can be split across columns or pages, which means that paginating content is much less likely to cause unexpected breakage in the styling, as discussed at face-to-face meeting afternoon of 2012-08-13.

Author: dbaron

css3-overflow/Overview.html

@@ -364,38 +364,36 @@ <h2 id=fragment-overflow><span class=secno>4. </span>Fragment overflow</h2>
   <p> When the computed value of ‘<code class=property>overflow</code>’
    for an element is ‘<code class=css>fragments</code>’, and
    implementations would otherwise have created a box for the element, then
-   implementations must create at least one box for that element. Each box
-   created for the element is called a <dfn id=fragment-box>fragment
-   box</dfn> for that element. (If an element with ‘<code
-   class=css>overflow: fragments</code>’ generates only one box, that box
-   is a <a href="#fragment-box"><i>fragment box</i></a>. However, if an
-   element's computed ‘<code class=property>overflow</code>’ is not
-   ‘<code class=css>fragments</code>’, then its box is not a <a
+   implementations must create a sequence of <dfn id=fragment-box>fragment
+   box</dfn>es for that element. (It is possible for an element with ‘<code
+   class=css>overflow: fragments</code>’ to generate only one <a
+   href="#fragment-box"><i>fragment box</i></a>. However, if an element's
+   computed ‘<code class=property>overflow</code>’ is not ‘<code
+   class=css>fragments</code>’, then its box is not a <a
    href="#fragment-box"><i>fragment box</i></a>.) Every <a
    href="#fragment-box"><i>fragment box</i></a> is a fragmentation container,
-   and for each <a href="#fragment-box"><i>fragment box</i></a> which ends
-   with a fragmentation break, (which could happen because breakable content
-   overflows in the block dimension or because of a forced break), there must
-   be another <a href="#fragment-box"><i>fragment box</i></a> created as a
-   next sibling of the previous one. <span class=issue>Or is it as though
+   and any overflow that would cause that fragmentation container to fragment
+   causes another <a href="#fragment-box"><i>fragment box</i></a> created as
+   a next sibling of the previous one. <span class=issue>Or is it as though
    it's a next sibling of the element? Need to figure out exactly how this
-   interacts with other box-level fixup.</span> (Breakable content might
-   overflow in the box dimension either because of a specified size on the <a
-   href="#fragment-box"><i>fragment box</i></a> or because the <a
-   href="#fragment-box"><i>fragment box</i></a> is within a fragmentation
-   context in which it is being broken. In other words, a single <a
-   href="#fragment-box"><i>fragment box</i></a> is never broken across
-   columns or pages; the pieces that are in separate columns or pages are
-   always distinct <a href="#fragment-box"><i>fragment box</i></a>es.)
-
-  <p class=issue> We also want ‘<code class=css>::nth-fragment()</code>’
-   pseudo-elements to be able to apply to the pieces of an element split
-   within a fragmentation context. Should we require that authors who want to
-   use ‘<code class=css>::nth-fragment()</code>’ in this way specify
-   ‘<code class=css>overflow:fragments</code>’ (even if they don't
-   specify a constrained height), or should it work automatically for all
-   elements even if they don't have ‘<code class=css>overflow:
-   fragments</code>’?
+   interacts with other box-level fixup.</span> However, fragment boxes may
+   themselves be broken (due to fragmentation in a fragmentation context
+   outside of them, such as pages, columns, or other fragment boxes); such
+   breaking leads to fragments of the same fragment box rather than multiple
+   fragment boxes. (This matters because fragment boxes may be styled by
+   their index; such breaking leads to multiple fragments of a fragment box
+   with a single index. This design choice is so that breaking a fragment box
+   across pages does not break the association of indices to particular
+   pieces of content.) <span class=issue>Should a forced break that breaks to
+   an outer fragmentation context cause a new fragment of a single fragment
+   box or a new fragment box?</span> <span class=issue>Should we find a term
+   other than <a href="#fragment-box"><i>fragment box</i></a> here to make
+   this a little less confusing?</span>
+
+  <p class=issue> What if we want to be able to style the pieces of an
+   element split within another type of fragmentation context? These rules
+   prevent ever using ‘<code class=css>::nth-fragment()</code>’ for that,
+   despite that the name seems the most logical name for such a feature.
 
   <div class=example>
    <table class=source-demo-pair>
@@ -631,8 +629,7 @@ <h4 id=style-of-fragments><span class=secno>4.1.2. </span>Styling of
     margin-bottom: 1em;
     height: 4em;
   }
-  .article::nth-fragment(n+2) {
-    /* 2 and up */
+  .article::nth-fragment(2) {
     margin-left: 5em;
     margin-right: 2em;
   }
@@ -866,8 +863,7 @@ <h3 id=max-lines><span class=secno>4.2. </span>The ‘<a
     font-size: 1.5em;
     max-lines: 3;
   }
-  .article::nth-fragment(n+2) {
-    /* 2 and up */
+  .article::nth-fragment(2) {
     column-count: 2;
   }
 &lt;/style&gt;

css3-overflow/Overview.src.html

@@ -259,42 +259,43 @@ <h2 id="fragment-overflow">Fragment overflow</h2>
 	<p>
 		When the computed value of 'overflow' for an element is ''fragments'',
 		and implementations would otherwise have created a box for the element,
-		then implementations must create at least one box for that element.
-		Each box created for the element is called a <dfn>fragment box</dfn>
+		then implementations must create a sequence of <dfn>fragment box</dfn>es
 		for that element.
-		(If an element with ''overflow: fragments'' generates only one box,
-		that box is a <i>fragment box</i>.
+		(It is possible for an element with ''overflow: fragments''
+		to generate only one <i>fragment box</i>.
 		However, if an element's computed 'overflow' is not ''fragments'',
 		then its box is not a <i>fragment box</i>.)
 		Every <i>fragment box</i> is a fragmentation container,
-		and for each <i>fragment box</i> which ends with a fragmentation break,
-		(which could happen
-		because breakable content overflows in the block dimension
-		or because of a forced break),
-		there must be another <i>fragment box</i> created as a next sibling
+		and any overflow
+		that would cause that fragmentation container to fragment
+		causes another <i>fragment box</i> created as a next sibling
 		of the previous one.
 		<span class="issue">Or is it as though it's a next sibling of
 		the element?  Need to figure out exactly how this interacts with
 		other box-level fixup.</span>
-		(Breakable content might overflow in the box dimension either
-		because of a specified size on the <i>fragment box</i>
-		or because the <i>fragment box</i> is within a fragmentation context
-		in which it is being broken.
-		In other words, a single <i>fragment box</i> is never broken
-		across columns or pages;
-		the pieces that are in separate columns or pages
-		are always distinct <i>fragment box</i>es.)
+		However, fragment boxes may themselves be broken
+		(due to fragmentation in a fragmentation context outside of them,
+		such as pages, columns, or other fragment boxes);
+		such breaking leads to fragments of the same fragment box
+		rather than multiple fragment boxes.
+		(This matters because fragment boxes may be styled by their index;
+		such breaking leads to multiple fragments of a fragment box
+		with a single index.
+		This design choice is so that
+		breaking a fragment box across pages does not break
+		the association of indices to particular pieces of content.)
+		<span class="issue">Should a forced break that breaks to
+		an outer fragmentation context cause a new fragment of a single
+		fragment box or a new fragment box?</span>
+		<span class="issue">Should we find a term other than
+		<i>fragment box</i> here to make this a little less confusing?</span>
 	</p>
 
 	<p class="issue">
-		We also want ''::nth-fragment()'' pseudo-elements
-		to be able to apply to the pieces of an element
-		split within a fragmentation context.
-		Should we require that authors who want to use
-		''::nth-fragment()'' in this way specify ''overflow:fragments''
-		(even if they don't specify a constrained height),
-		or should it work automatically for all elements
-		even if they don't have ''overflow: fragments''?
+		What if we want to be able to style the pieces of an element
+		split within another type of fragmentation context?
+		These rules prevent ever using ''::nth-fragment()'' for that,
+		despite that the name seems the most logical name for such a feature.
 	</p>
 
 	<div class="example">
@@ -516,8 +517,7 @@ <h4 id="style-of-fragments">Styling of fragments</h4>
     margin-bottom: 1em;
     height: 4em;
   }
-  .article::nth-fragment(n+2) {
-    /* 2 and up */
+  .article::nth-fragment(2) {
     margin-left: 5em;
     margin-right: 2em;
   }
@@ -722,8 +722,7 @@ <h3 id="max-lines">The 'max-lines' property</h3>
     font-size: 1.5em;
     max-lines: 3;
   }
-  .article::nth-fragment(n+2) {
-    /* 2 and up */
+  .article::nth-fragment(2) {
     column-count: 2;
   }
 &lt;/style&gt;